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Abstract 

Waterborne  mines  pose  an  asymmetric  threat  to  naval  forces.  Their  presence,  whether  actual  or 
perceived,  creates  a  low-cost  yet  very  powerful  deterrent  that  is  notoriously  dangerous  and  time- 
consuming  to  counter.  In  recent  years,  autonomous  underwater  vehicles  (AUV)  have  emerged 
as  a  viable  technology  for  conducting  underwater  search,  survey,  and  clearance  operations 
in  support  of  the  mine  countermeasures  (MCM)  mission.  With  continued  advances  in  core 
technologies  such  as  sensing,  navigation,  and  communication,  future  AUV  MCM  operations  are 
likely  to  involve  many  vehicles  working  together  to  enhance  overall  capability.  Given  the  almost 
endless  number  of  design  and  configuration  possibilities  for  multiple- AUV  MCM  systems,  it  is 
important  to  understand  the  cost-benefit  trade-offs  associated  with  these  systems. 

This  thesis  develops  an  analytical  framework  for  evaluating  advanced  AUV  MCM  system 
concepts.  The  methodology  is  based  on  an  existing  approach  for  naval  ship  design.  For  the 
MCM  application,  distinct  performance  and  effectiveness  metrics  are  used  to  describe  a  series 
of  AUV  systems  in  terms  of  physical/performance  characteristics  and  then  to  translate  those 
characteristics  into  numeric  values  reflecting  the  mission-effectiveness  of  each  system.  The  mis¬ 
sion  effectiveness  parameters  are  organized  into  a  hierarchy  and  weighted,  using  Analytical 
Hierarchy  Process  (AHP)  techniques,  according  to  the  warfighter’s  preferences  for  a  given  op¬ 
erational  scenario.  Utility  functions  and  modeling  provide  means  of  relating  the  effectiveness 
metrics  to  the  system-level  performance  parameters.  Implementation  of  this  approach  involves 
two  computer-based  models:  a  system  model  and  an  effectiveness  model,  which  collectively  per¬ 
form  the  tasks  just  described.  The  evaluation  framework  is  demonstrated  using  two  simple  case 
studies  involving  notional  AUV  MCM  systems.  The  thesis  conclusion  discusses  applications 
and  future  development  potential  for  the  evaluation  model. 
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Chapter  1 


Introduction 


1.1  Motivation 

1.1.1  The  Role  of  AUV  MCM  Systems  in  Naval  Operations 

Autonomous  underwater  vehicles  (AUV)  are  recognized  by  the  U.S.  Navy  as  a  vital  technology 
for  future  battlespace  preparation  and  tactical  operations  in  support  of  a  broad  range  of  warfare 
missions  [1].  Among  these  missions  is  mine  countermeasures  (MCM),  which  generally  consists 
of  two  sub-missions:  mine  reconnaissance  and  mine  clearance.  The  MCM  “mission  need”  is 
difficult  to  bound  since  it  is  tied  directly  to  the  larger  warfighting  requirements  of  sea  control 
and  access.  In  the  near-term,  the  Navy  is  focused  on  conducting  rapid,  in-stride  reconnaissance 
operations  in  the  littoral  region  to  enable  fast-paced  expeditionary  operations  [2],  [3].  Achieving 
this  level  of  capability  represents  a  significant  leap  from  that  of  today’s  MCM  force.  The 
true  MCM  mission  need  goes  far  beyond  in-stride  reconnaissance  to  include  such  challenging 
operational  scenarios  as  covert  surveillance,  detailed  bottom  mapping,  and  mine  clearance  -  all 
required  to  be  done  quickly,  over  large  areas,  and  from  deep  water  to  the  shoreline.  AUV  systems 
have  the  inherent  characteristics  to  satisfy  this  MCM  mission  need.  Increasingly  capable  and 
relatively  inexpensive,  these  systems  could  offer  the  naval  commander  unprecedented  leverage 
and  flexibility  in  conducting  rapid,  yet  thorough,  underwater  search  and  clearance  missions 
with  minimal  risk  to  human  life. 

Within  the  U.S.  defense  community,  many  underwater  vehicle  system  development  efforts 
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axe  presently  underway,  several  of  which  are  intended  for  the  MCM  mission.  The  Remote  Mine¬ 
hunting  System  (RMS)  is  an  unmanned  system  composed  of  a  semi-submersible  vehicle  and  a 
towed  body  collectively  housing  an  array  of  sonars.  It  is  to  be  back-fit  onboard  DDG  51  class 
destroyers,  beginning  in  2004,  to  provide  an  “organic”  mine  reconnaissance  capability  to  the 
fleet.  While  not  truly  an  AUV,  it  represents  an  incremental  step  toward  in-stride,  unmanned 
MCM.  Also  by  2004,  the  Navy  plans  to  introduce  its  first  tactical  unmanned  undersea  vehicle 
(UUV)1,  the  Long-term  Mine  Reconnaissance  System  (LMRS)  —  a  submarine-hosted  vehicle 
with  the  planned  capability  to  conduct  clandestine  mine  reconnaissance.  The  Office  of  Naval 
Research  (ONR)  is  funding  other  underwater  vehicle  research  and  development  efforts,  includ¬ 
ing  a  small  modified  oceanographic  AUV  called  SAHRV,  or  Semi-autonomous  Hydrographic 
Reconnaissance  Vehicle,  for  minehunting  in  very  shallow  water  regions[6].  Even  while  these 
pioneering  programs  are  being  implemented  during  this  decade,  continuing  advances  in  AUV 
technology  areas  coupled  with  expanding  confidence  in  AUV  performance  should  enable  steady 
progress  toward  more  unconventional  unmanned  MCM  systems.  In  their  1997  report  [5],  the 
National  Research  Council  Committee  on  Technology  for  Future  Naval  Forces  predicted  the 
availability  of  “highly  autonomous  UUVs  that  operate  in  cooperative  engagements”  and  are 
“capable  of  sensing  their  environments  and  communicating  with  each  other  to  optimize  under¬ 
water  missions”  in  the  2035  timeframe.  Relative  to  today’s  capability,  or  even  the  near-term 
capability  goals,  the  advent  of  these  “cooperative  multiple- AUV  systems”  will  lead  to  vastly 
superior  MCM  systems. 

1.1.2  Transition  to  Cooperative  Multiple- AUV  Operations 

Cooperative  multiple- AUV  systems  will  strive  to  enhance  overall  system  effectiveness  by  leverag¬ 
ing  the  individual  capabilities  of  vehicles  comprising  that  system.  These  individual  capabilities 
can  be  stated  in  terms  of  vehicle  sub-components,  e.g.  sensors,  navigation  units,  data  storage 
and  processing  devices,  communications  gear,  and  payload  items.  Functionally  linking  these 
physically  distributed  sub-components  is  communication ,  the  bedrock  capability  of  a  multiple- 
vehicle  system.  Without  intr a- system  communication,  the  benefits  of  employing  multiple  assets 

aThe  U.S.  Navy  often  uses  the  term  UUV  when  referring  to  unmanned  underwater  vehicle  systems.  An  AUV 
is  a  type  of  UUV. 
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are  reduced  to  the  trivial  case  of  cloning  vehicles  to  reduce  mission  time.  With  communication, 
however,  multiple-platform  paradigms  offer  opportunities  far  beyond  the  simple  linear  scaling  of 
performance.  Such  opportunities  include  multiple-sensor  data  fusion,  collaborative  navigation 
and  localization,  communications  relay,  and  optimal  asset  allocation.  The  presence  of  multi¬ 
ple  vehicles  within  a  system,  taken  together  with  the  probable  communication  link  between  the 
system  and  a  host  (e.g.  a  ship,  submarine,  satellite,  etc.),  also  impacts  the  guidance  and  control 
architecture  and  underlying  algorithms  required  for  the  system  to  function  properly. 

The  challenges  of  implementing  AUV  MCM  systems,  cooperative  multi- AUV  systems  aside, 
are  both  technological  and  operational  in  nature.  Beside  the  physical  issues  -  energy  source  and 
through- water  communication  being  two  of  the  most  daunting  -  there  are  significant  operational 
control  and  oversight  concerns  that  must  be  addressed.  Engineers,  systems  integrators,  and 
operators  will  have  to  sort  through  and  understand  these  issues  in  seeking  proper  balance 
between  overall  system  effectiveness  and  the  cost  required  to  achieve  it. 

1.2  Problem  Statement 

In  the  last  decade,  underwater  vehicle  research  has  led  to  great  advances  in  such  technologies  as 
sensing,  navigation,  guidance,  control,  and  communication.  To  reap  the  full  potential  of  these 
technologies,  AUVs  must  be  capable  of  working  together  in  a  cooperative  manner,  making  the 
best  use  of  their  complementary  capabilities.  Such  systems  may  be  composed  from  a  vast  range 
of  vehicle  types  and  sizes,  sensors,  navigation  suites,  communication  packages,  etc.,  resulting  in 
a  nearly  limitless  set  of  alternative  configurations.  For  this  reason,  the  design  and  employment  of 
a  cost-effective  multiple- AUV  system  requires  an  understanding  of  the  system’s  dynamics  and, 
in  particular,  the  relationships  between  system  configuration  and  performance  characteristics. 
Typical  questions  that  may  be  posed  by  decision-makers  are: 

1.  What  is  the  right  combination  of  AUV  assets  to  employ  for  a  particular  mission?  Should 
we  use  many  inexpensive  vehicles,  a  few  high-performance  vehicles,  or  a  combination  of 
the  two? 

2.  What  types  of  sensors  and  how  many  of  each  are  required  for  a  particular  mission?  What 
are  the  sizes  of  the  vehicles  that  must  carry  these  sensors? 
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3.  What  navigation  requirements  are  imposed  and  what  navigational  opportunities  are  cre¬ 
ated  by  multiple  vehicles? 

4.  What  are  the  communication  requirements  between  the  vehicles  and/or  the  Navy  host 
platform? 

These  are  important  and  difficult  questions,  and  they  must  be  answered.  Ultimately,  though, 
it  is  the  overall  system  effectiveness  -  the  degree  to  which  the  system  serves  its  intended  purpose 
-  that  must  be  assessed  in  order  to  make  appropriate  decisions  and  therefore  resolve  these  issues. 

1.3  Objectives 

The  overarching  objective  of  this  thesis  is  to  develop  an  analytical  framework  for  the  evaluation 
of  advanced  search  concepts  for  multiple- AUV  MCM. 

The  effort  described  herein  contributes  to  a  larger  project,  funded  by  ONR,  that  aims  to 
identify  and  evaluate  a  range  of  multiple- AUV  operational  paradigms  for  MCM  missions  [8]. 
This  project,  referred  to  as  the  “ONR  project”,  is  described  briefly  in  Section  2.1.  In  the 
early  stages  of  the  ONR  project,  the  author  and  other  participants  identified  the  need  for  two 
basic  levels  of  the  eventual  framework  that  would  be  used  to  evaluate  notional  AUV  systems. 
The  upper  level  would  provide  an  environment  for  rapidly  exploring  various  multi- AUV  system 
configurations  and  tactical  approaches  for  a  given  MCM  scenario.  The  lower  level  would  predict 
system  performance  and  behavior  in  each  case,  perhaps  through  high-fidelity  simulation,  and 
provide  the  results  to  the  upper  level.  The  thesis  focuses  on  the  development  of,  methodology 
behind,  and  application  for  the  overall  evaluation  framework. 

The  intended  thesis  “product”  is  a  computer-based  decision-making  tool.  At  the  outset  of 
the  work,  two  core  applications  were  identified  for  use  in  guiding  and  determining  the  scope  of 
the  project.  These  applications  are  presented  in  the  form  of  the  following  questions: 

1.  What  AUV  MCM  system,  in  terms  of  individual  vehicle  design(s)  and/or  multi- vehicle 
combinations,  most  affordably  meets  the  mission  need  and  requirements? 

2.  What  is  the  most  effective  system  configuration  and  operating  profile  for  an  AUV  system 
embarked  on  a  particular  mission? 
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The  first  question  relates  to  design  and  acquisition,  while  the  second  has  more  to  do  with 
operational  employment.  Realistically,  a  decision-maker  will  never  possess  the  knowledge  re¬ 
quired  to  answer  these  questions  definitively.  He  can  only  hope  to  obtain  the  “best”  solution 
by  exploring  the  cost-effectiveness  of  each  alternative  according  to  his  decision-making  criteria. 
In  support  of  the  overall  thesis  objective,  the  following  enabling  objectives  were  set: 

1.  Identify  performance  parameters  and  measures  of  effectiveness  for  multi- vehicle  MCM 
approaches. 

2.  Identify  and  select  advanced  multi- AUV  sensing  and  navigation  schemes  which  have  po¬ 
tential  for  minehunting  application. 

3.  Create  a  computer-based  multiple-AUV  performance  assessment  model. 

4.  Develop  a  cost-effectiveness  model  that  facilitates  translation  of  system  performance  char¬ 
acteristics  into  effectiveness  scores  and  cost  values. 

5.  Evaluate  the  cost-effectiveness  of  notional  multiple-AUV  systems. 

1.4  Outline 

The  thesis  is  organized  into  five  chapters  and  three  appendices.  Chapter  2  briefly  discusses  other 
research  efforts  related  to  the  use  of  underwater  vehicles  for  MCM.  Chapter  3  is  the  heart  of 
the  thesis.  It  details  the  methodology  behind  and  the  development  of  the  evaluation  framework. 
In  Chapter  4,  two  case  demonstrations  are  presented  to  illustrate  the  evaluation  approach.  A 
summary  of  the  thesis  and  a  short  discussion  of  applications  and  possible  follow-on  work  are 
given  by  Chapter  5.  The  appendices  contain  printouts  of  the  Evaluation  Model  developed  in 
the  thesis. 
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Chapter  2 


Related  Research 


2.1  Overview 

During  the  course  of  this  thesis,  the  author  became  aware  of  a  several  major  MCM  systems 
research  efforts  being  conducted  by  members/associates  of  the  MCM  community.  In  general, 
these  fall  into  two  broad  application  categories:  very  shallow  water  and  surf  zone  (VSW/SZ), 
shallow  water  and  deeper  (SW).  ONR  currently  funds  a  large  number  of  individual  and  group 
projects  that  contribute  to  these  efforts.  Some  of  the  organizations  undertaking  or  involved  in 
these  projects  include: 

Coastal  Systems  Station  (CSS),  Dahlgren  Division,  Naval  Surface  Warfare 
Center  (NSWC);  Panama  City,  Florida 
Naval  Undersea  Warfare  Center  (NUWC);  Newport,  Rhode  Island 
Massachusetts  Institute  of  Technology  (MIT) 

Jolias  Hopkins  University  (JHU),  Applied  Physics  Laboratory  (APL) 

Applied  Research  Laboratory  (ARL),  University  of  Texas  (UT)  at  Austin 

Brief  descriptions  of  those  research  efforts  most  applicable  to  this  thesis  are  provided  in  the 
following  sections.  To  at  least  some  degree,  the  author  collaborated  with  members  from  each 
of  these  organizations  during  the  course  of  the  thesis. 
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2.2  MIT  Ocean  Engineering  Department 


As  previously  stated,  the  thesis  contributes  to  a  joint  MIT  Sea  Grant  -  Bluefin  Robotics  Cor¬ 
poration  project,  funded  by  ONR,  titled  Sensor  and  Operational  Trade-offs  for  Multiple  AUV 
MCM.  The  objective  of  the  project  is  “to  develop  the  tools  necessary  to  create  a  simulation 
environment  in  which  to  conduct  sensor  and  platform  trade-off  studies  for  MCM  missions  involv¬ 
ing  multiple  AUVs” .  As  proposed,  the  work  will  lead  to  an  advanced  multi- vehicle  simulation 
capability  using  high-fidelity  physics-based  models. 

While  working  on  this  thesis,  the  author  communicated  regularly  with  other  members  of 
the  ONR  project  team.  The  framework  developed  herein  will  be  used  to  guide  the  continued 
multi- AUV  simulation  and  modeling  effort. 

In  addition  to  the  ONR  project,  several  ongoing  research  efforts  within  the  MIT  Ocean 
Engineering  Department  are  applicable  to  the  AUV  concepts  and  technologies  motivating  this 
thesis.  The  research,  mostly  Navy-funded,  can  be  categorized  under  the  fields  of  ocean  acoustics 
and  underwater  vehicle  navigation. 

Professor  Henrik  Schmidt,  who  is  the  Principal  Investigator  for  the  ONR  project  and  the 
advisor  for  this  thesis,  is  currently  engaged  in  a  project  examining  new  sonar  concepts  for 
shallow-water  MCM.  The  project,  called  GOATS2,  involves  expanding  a  previously  developed 
multi- AUV  concept  known  as  Autonomous  Oceanographic  Sampling  Network  (AOSN)  [10]. 
During  GOATS  experiments  in  1998  and  2000,  participants  explored  the  use  of  multiple,  mo¬ 
bile  platforms  for  mono-,  bi-,  and  multi-static  sensing  and  3-D  mapping  of  bottom  objects, 
including  buried  mines  [9].  These  experiments  have  revealed  the  potential  benefits  of  us¬ 
ing  multiple,  distributed  AUVs  to  cooperatively  conduct  MCM  searches  in  the  VSW  region 
of  the  littoral.  An  expected  by-product  of  this  work  is  the  capability  to  acoustically  model 
advanced  multi- AUV  sensing  concepts.  Such  models  will  hopefully  predict  system-level  detec¬ 
tion/classification/identification  probabilities  of  notional  multi- sensor  configurations,  and  would 
nicely  complement  the  evaluation  framework  developed  in  this  thesis. 

The  ability  to  conduct  clandestine  MCM  operations  will  require  AUV  systems  to  navigate 
with  high  accuracy,  ideally  without  having  to  penetrate  the  surface  at  all.  Professor  John 

2  Generic  Oceanographic  Array  Technology  System 


14 


Leonard’s  research  is  concentrated  in  the  area  of  advanced  navigation  and  mapping  technologies 
for  underwater  vehicles.  In  recent  years,  a  main  thrust  has  been  feature-based  concurrent 
mapping  and  localization  (CML),  a  technique  which  enables  an  AUV  to  build  a  map  of  an 
unknown  environment  while  simultaneously  using  that  map  to  navigate  with  bounded  position 
error  [11].  The  feature-based  CML  approach  relies  on  high-resolution  sonar  data  from  which 
compact  features,  such  as  mines,  lobster-traps,  rock  outcroppings,  and  so  forth  can  be  extracted. 
These  features  are  then  used  to  build  the  map  that  the  AUV  can  use  to  determine  its  position 
and  navigate  from  over  an  extended  period  of  hours  or  days.  This  research  is  sponsored  by 
NUWC. 

2.3  MCM  Future  Systems  Working  Group 

JHU/APL,  ARL:UT,  and  CSS  Panama  City  constitute  the  core  of  the  MCM  Future  Systems 
Working  Group.  MIT  and  several  other  organizations  are  designated  as  supporting  members  of 
this  working  group.  Since  January  1998,  the  group  has  developed  an  array  of  system  concepts, 
identified/researched  future  technologies,  established  performance  metrics,  and  conducted  a 
significant  amount  of  analysis,  mostly  geared  toward  underwater  vehicle  systems  for  the  SW 
MCM  problem.  Models  developed  include  a  UUV  endurance  model  and  associated  cost  model, 
and  a  MATLAB-based  model  for  MCM-related  calculations  for  UUVs.  These  models  have  been 
used  to  assess  the  MCM  efforts  of  multiple  underwater  vehicles,  but  they  are  not  intended  for 
cooperative  multi- vehicle  systems.  The  evaluation  framework  developed  in  this  thesis  leverages 
some  of  the  research  provided  by  the  working  group,  and  is  intended  to  complement  their  efforts. 

2.4  Naval  Warfare  Centers 

CSS  and  NUWC  are  two  Navy  warfare  centers  possessing  a  great  deal  of  capability  for  UUV 
research  and  engineering.  Additionally,  CSS  is  very  involved  in  a  broad  range  of  MCM  systems 
engineering  and  analysis,  with  programs  for  surface-,  air-,  and  underwater-based  MCM.  At  CSS, 
work  is  being  done  in  support  of  both  the  VSW/SZ  and  SW  problems.  Most  applicable  to  this 
thesis  axe  high-level  simulation/evaluation  analyses  being  performed  for  UUVs  in  the  VSW/SZ 
problem,  and  separately  for  comparing  unmanned  surface  vehicles  (USV)  MCM  system  concepts 
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to  UUV  concepts.  NUWC  has,  in  the  past,  been  aligned  with  the  anti-submarine  warfare 
community  and  had  little  opportunity  to  participate  in  MCM  system  R&D  work.  However,  the 
introduction  of  LMRS  and  other  potential  submarine-based  and/or  undersea  warfare  UUVs  has 
caused  NUWC  to  become  involved  in  MCM  system  development.  NUWC  is  also  tasked  with 
drafting  and  managing  the  Navy’s  UUV  Master  Plan  —  a  visionary  document  establishing  the 
broad  missions  and  required  capabilities  for  all  Navy  UUVs  [1]. 
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Chapter  3 


Evaluation  Framework 

The  objective  of  this  thesis  is  to  develop  a  framework  for  the  evaluation  of  advanced  search 
concepts  for  multi- AUV  MCM.  Chapter  3  addresses  the  development  and  architecture  of  this 
framework. 


3.1  Approach 

In  the  general  context  of  warfare  systems,  determining  the  “right”  system  for  a  particular  mis¬ 
sion  need  is  a  complex  and  challenging  endeavor.  From  the  early  design  phase  to  operational 
implementation,  the  process  of  fielding  a  typical  warfare  system  involves  many  parties,  each 
of  whom  make  decisions  according  to  a  different  set  of  criteria.  A  designer  tends  to  focus  on 
specific,  intrinsic  system  characteristics  (e.g.  size,  speed,  and  efficiency)  that  allow  optimization 
of  the  system  from  an  engineering  standpoint,  while  the  end  user  is  concerned  about  the  extent 
to  which  the  system  satisfies  their  own  set  of  preferences  or  objectives.  Additional  parties  may 
also  impose  objectives  or  constraints  of  their  own,  such  as  cost  or  production  schedule.  Eval¬ 
uating  the  overall  cost-effectiveness  of  a  system  is  further  complicated  when  the  system’s  role 
in  a  larger  “system  of  systems”  is  considered.  For  warfare  system  design  and  implementation, 
these  realities  demand  a  decision-making  framework  which  integrates  the  contributions  and 
preferences  of  all  parties  and  measures  the  system’s  effectiveness  at  the  highest  practical  level 
of  the  system  of  systems  hierarchy. 

An  integrated  design  decision-making  approach  is  used  to  varying  degrees  within  the  U.S. 
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Navy  for  system  design  and  acquisition.  Navy  program  offices  and  their  supporting  warfare  and 
analysis  centers  evaluate  system  alternatives  through  a  process  called  Analysis  of  Alternatives 
(AO A),  which  formalizes  the  procedure  for  assessing  and  documenting  trade-offs  associated 
with  major  program  decisions  [12].  In  the  AOA  process,  the  “value”  of  a  particular  system 
alternative  is  established  using  parameters  called  measures  of  effectiveness  (MOE)  and  measures 
of  performance  (MOP).  The  manner  in  which  these  MOE  and  MOP  are  identified  and  evaluated 
to  support  decision-making,  however,  is  not  rigidly  established  and  so  their  use  varies  widely. 
In  recent  years,  naval  ship  design  curriculums  at  both  Naval  Post-graduate  School  (NPS)  and 
Massachusetts  Institute  of  Technology  (MIT)  have  adopted  “total  ship  system  engineering” 
approaches  to  naval  ship  design.  These  approaches  generally  employ  mission-oriented  MOE 
and  system-oriented  MOP,  prioritized  via  a  system  hierarchy,  to  evaluate  the  cost-effectiveness 
of  several  ship  or  submarine  design  alternatives  with  respect  to  the  mission  requirements. 

As  a  first  step  toward  defining  a  multi- AUV  MCM  system  evaluation  framework,  it  is  useful 
to  compare  the  circumstances  surrounding  the  evaluation  of  a  multi- AUV  MCM  system  versus  a 
naval  ship.  The  basic  objective  for  each  is  the  same:  to  identify  the  most  cost-effective  solution 
as  measured  against  the  collective  set  of  criteria  established  by  all  parties  involved  in  the  process. 
Additionally,  in  each  case,  the  set  of  effectiveness  criteria  is  derived  from  a  warfare  mission  to 
which  other  systems  or  platforms  are  also  making  a  contribution.  There  are  several  striking 
differences  between  the  two  cases,  however.  One  is  found  by  considering  their  physical  layouts. 
The  ship  is  a  single  unit,  while  the  multi- AUV  system  is,  of  course,  a  collection  of  individual 
vehicles.  Adding  to  this  contrast,  the  vehicle  composition  of  a  multi- AUV  system  could  vary, 
even  within  a  given  mission  scenario3.  Beyond  the  physical  differences  lie  unique  operational 
and  system  dynamics  issues  associated  the  “virtually  connected”  and  artificially  intelligent 
multi-AUV  system.  Based  on  these  characteristics,  a  multi-AUV  system  could  be  considered, 
from  an  evaluation  standpoint,  analogous  to  the  networked  task  force  or  battle  group  directly 
above  the  naval  ship  in  the  system  hierarchy.  Interestingly,  the  AUV  system  is  itself  part  of 
that  same  task  force  (since  its  pin-pose  is  to  conduct  MCM  operations  on  behalf  of  the  other 
members  of  that  force).  A  framework  for  evaluating  multi-AUV  systems  must,  therefore,  be 

3  This  statement  presumes  that  future  AUV  systems  will  consist  of  re-configurable  and  operationally  flexible 
platforms  that  facilitate  low-cost  ’’mixing  and  matching”  of  not  only  vehicle  sub-systems,  but  vehicle  types  within 
the  system  as  well. 
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structured  to  handle  the  determination  of  effectiveness  on  several  system  hierarchy  levels. 

The  evaluation  framework  proposed  in  this  thesis  is  based  primarily  on  an  approach  pre¬ 
sented  by  Hockberger  [13]  for  naval  ship  design.  Hockberger  combines  several  well-known 
systems  engineering  practices  and  decision-making  methods  in  a  framework  suitable  for  naval 
ship  design,  emphasizing  the  importance  of  determining  the  ship’s  effectiveness  in  the  context 
of  its  “supersystem” .  The  proposed  framework  also  incorporates  techniques  used  by  Whit¬ 
comb  [14].  Whitcomb’s  approach,  which  is  itself  based  partly  on  the  work  of  Hockberger,  uses 
multiple-criteria  decision-making  (MCDM)  methods  to  integrate  multiple  customer  and  com¬ 
pany  preferences  into  the  product  design  optimization  process.  The  multi-AUV  MCM  system 
evaluation  framework  presented  here  provides  an  environment  in  which  various  system  con¬ 
cepts,  as  defined  by  a  system  designer,  can  be  evaluated  in  terms  of  overall  cost-effectiveness 
from  the  perspective  of  the  warfighter. 

3.2  Framework  Architecture  and  Components 

The  evaluation  framework  consists  of  two  main  components:  an  effectiveness  model  and  a  system 
model.  A  third  component  —  the  cost  model  —  is  required  to  complete  the  framework.  For  this 
thesis,  cost  estimates  for  AUV  MCM  systems  are  obtained  using  an  underwater  vehicle  cost 
model  developed  for  the  MCM  Future  Systems  Study  discussed  in  Section  2.3.  The  effectiveness 
and  system  models  are  analytical  in  nature,  meaning  they  use  mathematical  relationships  to 
describe  the  system.  As  with  any  modeling  effort,  maintaining  a  balance  between  robustness, 
validity,  programming  effort,  and  flexibility  required  careful  planning  and  structuring  of  the 
model  environment.  In  this  case,  the  general  approach  was  to  make  the  higher  levels  of  the 
model  as  generic  as  possible,  and  to  increase  detail  and  resolution  with  each  progression  into 
the  lower  levels.  This  was  accomplished  by  developing  separate  model  sub-components  and 
linking  them  together  to  form  the  overall  system  model,  thereby  achieving  robustness  without 
losing  flexibility.  Figure  3-1  illustrates  the  relationship  between  the  framework  components  as 
envisioned  early  in  the  development  process. 
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Figure  3-1:  Evaluation  Framework  Model  Components 

3.2.1  Effectiveness  Model  Component 

The  effectiveness  model  addresses  the  objectives  of  the  warfighter.  These  objectives  are  based 
on  the  mission,  and  are  completely  external  to  the  system  employed  to  pursue  them.  At  the 
same  time,  it  is  essential  that  the  objectives  selected  to  represent  the  mission  are  a  “complete, 
consistent,  and  correct”  set  of  objectives  with  respect  to  the  system(s)  being  evaluated  [13]. 
An  appropriate  set  of  objectives  can  be  selected  and  organized  using  common  problem-solving 
and  decision-making  techniques,  such  as  Quality  Function  Deployment  (QFD)  [16]  and  the 
Analytical  Hierarchy  Process  (AHP)  [17].  AHP  is  also  an  excellent  tool  for  generating  the 
priorities,  or  relative  weights,  of  the  objectives  at  each  level  in  the  effectiveness  model  in  order 
to  capture  which  aspects  of  the  mission  are  most  important  to  the  warfighter.  Another  key 
aspect  of  the  effectiveness  model  is  the  use  of  MOE.  MOE  measure  the  extent  to  which  a 
system  achieves  the  warfighter’s  objectives.  They  can  be  given  in  terms  of  real  units  (e.g. 
knots)  or  as  a  scaled  or  normalized  numerical  score  (e.g.  0.75  on  a  scale  of  0  to  1).  MOE  values 
are  necessarily  dependent  on  system  characteristics  through  sometimes  difficult-to-establish 
relationships  (discussed  later).  When  properly  selected,  organized,  weighted,  and  informed,  the 
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MOE  set  provides  a  concise  structure  for  presenting  the  effectiveness  of  a  system  alternative. 


3.2.2  System  Model  Component 

The  system  model  plays  two  complementary  roles  in  the  evaluation  framework.  First,  it  provides 
a  design  environment  in  which  the  “user”  defines  a  multi- AUV  system  in  terms  of  its  basic  sub¬ 
components  (e.g.  sensors,  navigation  packages)  and  their  associated  performance  characteristics 
and  then  “balances”  that  system  to  satisfy  certain  design  requirements  and  constraints.  Like 
most  engineering  models,  the  system  model  employs  mathematical  relationships  to  describe 
the  interaction  between  the  system’s  components  and  to  ensure  compliance  with  the  basic 
laws  of  physics.  By  working  through  the  system  design  process  and  observing  the  effects  on 
system  performance/effectiveness,  the  designer  gains  at  least  a  partial  understanding  of  the 
system’s  functional  behavior.  The  second  role  of  the  system  model  is  to  estimate  the  physical 
and  performance  characteristics  of  a  multi- AUV  system.  These  characteristics  are  presented  as 
MOP1,  which  are  then  used  as  inputs  to  the  effectiveness  model. 

3.2.3  Integration  of  the  Model  Components 

The  effectiveness  and  system  models  can  be  viewed  as  agents  working  on  behalf  of  the  key  players 
involved  in  multi- AUV  MCM  system  implementation.  The  effectiveness  model  represents  the 
warfighter,  whose  objectives  are  tied  to  mission  scenarios  which  demand  some  level  of  MCM 
effort.  The  system  model  represents  the  designer  or  engineer,  whose  task  is  to  optimize  the 
system  within  the  bounds  of  some  set  of  requirements  and  constraints.  The  role  of  the  agents 
is  to  establish  a  link  between  the  efforts  of  the  designer  and  the  objectives  of  the  warfighter  so 
that,  in  effect,  the  designer’s  frame  of  reference  for  optimization  of  the  system  is  expanded  to  be 
the  warfighter’s  objectives.  By  doing  so,  a  conceptual  multi- AUV  MCM  system  configuration 
can  be  evaluated  in  terms  of  its  ability  to  satisfy  the  mission  requirements  rather  than  specific 
performance  requirements  that  mean  little  to  the  warfighter. 

Of  course,  other  players  may  be  involved  in  the  process,  and  their  interests  must  be  repre¬ 
sented  as  well.  Such  interests  may  include  manufacturing  capabilities,  technology  limitations, 

lfThe  distinction  between  MOE  and  MOP  is  critical  to  understanding  the  framework  developed  in  this  the¬ 
sis  and,  beyond  that,  for  all  applications  that  use  these  parameters.  In  short,  MOE  are  tied  to  the  mission 
(alternatively:  the  customer’s  requirements)  while  MOP  are  properties  of  the  system  (or  product). 
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and  cost.  Often,  these  interests  are  addressed  through  constraints  imposed  directly  on  the  de¬ 
signer.  Cost,  however,  generally  warrants  independent  consideration  for  several  reasons.  First, 
cost  is  somewhat  unique  in  that  several  parties  may  have  a  vested  interest  in  it,  depending 
on  the  type  of  cost  considered  and  the  context  of  the  evaluation.  Acquisition  cost  is  usually 
linked  to  annual  defense  budget  constraints,  as  mandated  by  Congress,  while  the  impact  of 
life  cost  (e.g.  operations,  support,  maintenance)  concerns  decision-makers  at  many  levels,  from 
Congress  who  allocates  the  money,  to  the  warfighter  who  must  carefully  manage  their  fiscal 
resources.  Second,  cost  constraints  are  difficult  to  establish.  Decision-makers  would  prefer  to 
get  the  “most  for  their  money”  rather  than  draw  the  line  at  some  arbitrary  upper  cost  limit. 
Given  these  unique  characteristics,  cost  is  best  treated  as  a  separate  parameter  against  which 
the  mission-effectiveness  of  the  system  can  be  compared. 

The  effectiveness  model  and  system  model  are  linked  by  defining  either  qualitative  or  quan¬ 
titative  relationships  between  the  MOP  of  the  system  model  and  the  MOE  of  the  effectiveness 
model.  Since  MOE  require  input  from  one  or  more  MOP,  an  MOE  is  said  to  be  a  function 
of  MOP.  Techniques  for  establishing  the  MOE-MOP  relationships  include  modeling/simulation 
and  direct  assessment  [13],  [14].  Modeling  and  simulation  efforts  require  a  significant  initial 
time  investment  and  can  be  restrictive.  However,  if  implemented  properly,  they  permit  rapid 
evaluation  of  complex  problems  and  may  be  used  repeatedly  for  similar  applications.  Direct 
assessment  involves  a  dialog  between  the  evaluator  and  decision-maker.  Based  on  the  results 
of  the  evaluator/decision-maker  interaction,  the  evaluator  constructs  a  utility  function  which 
reflects  the  judgement,  preference,  and/or  experience  of  the  decision-maker.  Since  each  tech¬ 
nique  has  certain  strengths  and  weaknesses,  many  evaluations  use  both  techniques  either  for 
separate  aspects  or  to  augment  one  another. 

3-3  The  Overall  Evaluation  Process 

Whether  for  design-  or  employment-related  decisions,  a  formal  evaluation  process  is  needed 
to  properly  and  consistently  assess  multi- AUV  system(s)  cost-effectiveness.  This  process  in¬ 
volves  three  basic  phases:  problem,  definition ,  generation  of  solution  alternatives ,  and  model¬ 
ing/evaluation  of  alternatives.  The  problem  definition  phase  is  associated  with  the  effectiveness 
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Figure  3-2:  Evaluation  Process  Flowchart 

model.  During  this  phase,  the  overall  mission  is  defined  and  the  appropriate  MOE  hierarchy 
established.  Next,  operational  scenario (s)  are  defined  which  characterize  the  environment  and 
mine  threat.  Based  on  the  mission  and  the  operational  scenario(s),  MOE  weights  must  be  deter¬ 
mined.  These  weights  should  reflect  the  warfighter’s  opinions  regarding  the  relative  importance 
of  each  MOE.  (A  method  for  determining  these  weights  is  discussed  in  Section  3.4.4) 

Once  the  mission  aspects  are  addressed  and  the  effectiveness  model  is  set  up,  the  assessor 
develops  alternative  solutions  to  be  evaluated,  along  with  corresponding  MOP.  If  not  already 
known,  the  MOE-MOP  relationships  must  be  derived.  This  is  considered  the  beginning  of 
the  modeling  and  evaluation  phase.  Next,  each  system  concept  is  designed/modeled  in  order  to 
arrive  at  MOP  and,  therefore,  MOE  values.  With  a  determination  of  system  cost,  the  MOE  and 
cost  results  are  then  available  for  evaluation  and/or  comparison  to  other  system  alternatives. 
Figure  3-2  shows  the  full  sequence  of  events  for  the  evaluation  process5. 

The  entire  process  must  be  completed  for  the  setup  of  a  new  problem  in  order  to  develop 

5 This  AUV  system  evaluation  process  was  derived  from  the  ’’early  stage  ship  design  process”  presented  by 
Hockberger. 
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Figure  3-3:  Streamlined  Evaluation  Process  Flowchart 

the  model (s)  and  establish  all  necessary  relationships.  Once  this  has  been  done,  however,  the 
basic  model  structure  should  accommodate  any  number  of  evaluation  problems  that  fall  under 
the  overall  mission.  This  includes  changing  the  operational  scenario,  which  would  require 
modification  to  the  MOE  weights,  but  should  not  affect  the  MOE  hierarchy.  Depending  on  the 
way  the  lower- level  system  model  was  developed,  there  may  be  some  restriction  on  the  types 
of  AUV  systems  that  it  can  handle.  If  this  is  the  case,  the  system  model  can  be  modified  or 
replaced.  The  only  requirement  for  the  system  model  is  that  it  provide  the  necessary  MOP  for 
determining  the  mission-specific  MOE.  The  tailored  process,  for  evaluating  system  alternatives 
after  the  initial  problem  setup,  is  illustrated  in  Figure  3-3. 

With  the  overall  AUV  system  evaluation  process  defined,  Sections  3.4  and  3.5  discuss  the 
development  of  the  effectiveness  model  and  system  model,  respectively. 
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3.4  Effectiveness  Model 


3.4.1  Overview 

Two  main  intentions  guided  the  development  of  an  effectiveness  model.  First,  the  model  would 
facilitate  the  broadest  possible  range  of  notional  underwater  vehicle  system  designs,  configu¬ 
rations,  and  operational  employment  scenarios.  Second,  the  MOE  selected  would,  so  far  as 
possible,  be  consistent  with  current  or  emerging  U.S.  Navy  doctrine.  To  comply  with  these  in¬ 
tentions,  appropriate  resources  were  obtained  through  Navy  contacts  and  communication  was 
established  with  other  groups  engaged  in  underwater  vehicle  MCM  efforts  (see  Chapter  2). 

The  following  subsections  present  the  AUV  MCM  System  Effectiveness  Model,  developed  as 
the  first  major  component  of  the  overall  evaluation  framework.  The  proper  name  “Effectiveness 
Model”  is  used  to  distinguish  the  particular  model  developed  for  the  thesis  from  the  more  generic 
effectiveness  model  previously  discussed. 

3.4.2  Mission  and  Operational  Requirements 

Following  the  established  evaluation  process  (Figure  3-2),  the  overall  mission  was  identified  as 
MCM.  Assuming  that  the  subject  of  the  entire  evaluation  framework  was  AUV  MCM  systems, 
the  system-specific  operational  requirements  were  defined  as  follows: 

1.  Conduct  MCM  operations,  including  mine  reconnaissance  (detection,  classification,  iden¬ 
tification,  and  localization)  and  mine  clearance  (neutralization).6 

2.  Conduct  operations  with  minimal  reliance  on  support  platforms. 

3.  Conduct  clandestine  operations  (as  needed). 

4.  Communicate  with  host  platform  or  entity. 

6 In  official  U.S.  Navy  mine  warfare  terminology,  the  four  levels  of  MCM  effort  are  detection,  classifica¬ 
tion,  identification,  and  neutralization.  Detection  corresponds  to  discovering  an  object,  classification  determines 
whether  the  object  is  minelike  or  not,  identification  refers  to  positive  designation  as  a  mine,  and  neutralization 
removes  the  threat.  Localization,  which  an  important  step  for  mapping  and/ or  reacquisition  of  mine  contacts, 
is  sometimes  included  as  a  fifth  level. 
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3.4.3  MOE  Determination 

The  Navy’s  Program  Executive  Office  for  Mine  Warfare  (PEO(MIW))  defines  MOE  and  MOP 
that  address  today’s  mine  warfare  practices  and  systems.  These  metrics,  largely  geared  toward 
surface-  and  air-based  MCM  systems,  are  designed  to  standardize  the  procedures  for  data 
collection  and  system  evaluation  throughout  the  fleet,  yet  are  not  intended  to  be  all-inclusive 
or  restrictive  [15].  The  existing  MOE  fall  short  of  fully  describing  the  potential  capabilities  of 
advanced  underwater  vehicle  MCM  systems. 

The  Effectiveness  Model  MOE  were  established  by  considering  the  operational  requirements 
for  AUV  MCM  systems  and  comparing  those  requirements  to  the  existing  MOE  to  determine 
where  modifications  and  additions  were  needed.  PEO(MIW)  Instruction  3370  [15]  defines  two 
force-level  MOE:  Time  and  Risk.  The  Time  MOE  refers  to  the  time  required  to  execute  the 
specified  mission,  while  the  Risk  MOE  addresses  the  vulnerability  of  transiting  platforms  and 
MCM  vehicles  to  the  encountered  minefield.  Depending  on  the  particular  application,  these 
MOE  are  determined  from  some  combination  of  system/platform-level  MOP.  The  Instruction 
defines  thirty-two  MOP.  Examples  include:  sensor  probabilities  of  detection,  classification, 
and  identification;  probabilities  of  mine-to-target  actuation  and  subsequent  damage,  and  other 
platform  characteristics  such  as  transit  speed  to  the  area,  search  speed,  time  to  turn,  and 
endurance.  A  review  of  the  MOE  and  their  application  to  AUV  MCM  systems  led  to  the 
following  conclusions: 

•  Near  real-time  communications  may  be  desired  with  the  AUV  system.  The  vehicles 
abilities  to  relay  information  between  themselves  and  to  the  surface  (to  a  ship  or  satellite) 
will  need  to  be  measured. 

•  Covertness  is  one  of  the  primary  benefits  of  an  AUV  system.  This  trait  should  be  measured 
and  incorporated  into  a  measure  of  effectiveness. 

•  AUVs,  despite  their  name,  will  still  require  some  level  of  logistics  support,  for  deployment 
and  recovery  at  least.  This  impact  on  the  overall  system  effectiveness  must  be  accounted 

for. 

•  Human  guidance/oversight  of  any  system  imposes  demands  on  manning  and  other  re- 
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sources,  and  should  be  considered  during  system  evaluation. 

•  Unmanned  systems  do  not  possess  the  same  risk  characteristics  as  manned  systems.  This 
aspect  of  the  Risk  MOE  should  be  examined  for  possible  modification. 

Based  on  the  review,  three  new  MOE  were  incorporated:  Autonomy,  Communication,  and 
Covertness.  A  closer  look  at  some  of  the  contrasts  between  surface-  or  air-based  MCM  systems 
and  underwater-based  systems  provides  some  added  justification  for  these  new  MOE.  MCM 
ships  and  aircraft  today  have  essentially  equivalent  communication  and  covertness  characteris¬ 
tics  relative  to  each  other.  Their  communication  abilities  are  extensive,  while  their  ability  to 
conduct  covert  operations  is  almost  non-existent.  For  AUVs,  and  especially  for  multiple-vehicle 
systems,  covertness  and  communication  abilities  may  vary  significantly  depending  on  the  com¬ 
position  and  configuration  of  the  system.  This  variability  also  applies  to  support/oversight 
requirements  for  underwater  vehicle  systems,  whereas  conventional  systems  have  fairly  uniform 
requirements. 

The  existing  Time  MOE  was  adopted  without  modification,  except  to  rename  it  Mission 
Time.  The  Risk  MOE,  however,  was  extensively  modified  and  renamed  Mission  Accomplish¬ 
ment.  The  Mission  Accomplishment  MOE  focuses  on  the  end  condition  of  the  searched  or 
cleared  area  rather  than  the  vulnerability  of  transiting  or  MCM  platforms. 

These  five  MOE  -  Mission  Time ,  Mission  Accomplishment ,  Autonomy ,  Communication, 
and  Covertness  -  form  the  upper  level  of  the  MOE  hierarchy,  as  shown  in  Figure  3-4.  In 
anticipation  of  the  need  to  link  these  MOE  to  the  system  MOP,  the  MOE  were  decomposed 
to  form  a  second  level  of  subordinate  MOE.  A  brief  description  of  each  MOE  and  sub-MOE 
-follows. 

Mission  Time 

The  Mission  Time  MOE  represents  the  time  required  for  the  AUV  system  to  complete  the 
assigned  mission  objectives.  This  is  best  expressed  in  terms  of  the  effective  area  coverage  rate 
(ACR),  expressed  in  square  nautical  miles  per  hour.  The  effective  ACR  is  defined  as  the  ratio  of 
the  total  search  area  to  the  total  amount  of  time  required  to  complete  the  mission  objective(s), 
from  AUV  system  deployment  to  recovery.  This  includes  time  spent  in  the  search  area  plus 
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Figure  3-4:  AUV  MCM  System  Effectiveness  Model  Hierarchy 

transit  time  to/from  the  search  area.  An  alternative  sub-MOE  is  just  the  total  mission  time, 
given  in  hours. 

Mission  Accomplishment 

The  Mission  Accomplishment  MOE  represents  the  estimated  condition  of  the  searched/cleared 
area  after  the  mission  is  completed.  This  MOE  reveals  the  extent  to  which  any  specified 
mission  objectives  were  achieved  or  surpassed.  The  two  basic  classes  of  MCM  missions  are 
mine  reconnaissance  and  mine  clearance.  The  evaluation  framework  assumes  that,  for  a  given 
evaluation  problem,  only  one  of  these  missions  will  be  in  play.  In  other  words,  all  systems 
being  evaluated  and  compared  will  be  operating  under  the  same  mission,  either  reconnaissance 
or  clearance.  Two  of  the  three  sub-MOE  apply  to  the  reconnaissance  mission:  search  level 
and  localization  accuracy.  For  the  recon  mission,  these  two  sub-MOE  are  weighted  relative 
to  each  other,  and  the  clearance  level  sub-MOE  receives  a  zero  weight.  Search  level  refers 
to  the  cumulative  probability  of  detecting,  classifying,  and  correctly  identifying  mines  within 
the  specified  search  area.  It  is  also  commonly  referred  to  as  “percent  search  .  Localization 
accuracy  represents  the  distance  error  between  the  reported  mine  positions  and  the  actual  mine 
positions,  or  “contact  position  error”.  For  this  model,  the  contact  position  error  is  taken  as  a 
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function  of  the  system  navigation  error,  the  latter  normally  given  as  a  percentage  of  distance 
traveled7.  For  a  clearance  mission,  clearance  level  is  given  a  weight  of  unity,  and  the  other  sub- 
MOE  are  zero.  Clearance  level  refers  to  the  cumulative  probability  of  detecting,  classifying, 
identifying  (optional) ,  and  neutralizing  mines  within  the  specified  search  area,  and  is  also  known 
as  “percent  clearance”.  For  this  thesis,  the  system  model  was  not  developed  to  describe  mine 
clearance  operations. 

Autonomy 

The  Autonomy  MOE  represents  the  independence  of  the  system  from  logistics  support  and/or 
oversight  for  guidance  and  tasking.  Two  subordinate  MOE  comprise  the  Autonomy  MOE: 
Lift  Support  and  Host  Support.  Lift  support  measures  the  amount  of  cargo  space  required 
for  deployment/recovery  of  the  system,  given  in  terms  of  area  (e.g.  sqft).  Host  Support  refers 
to  the  level  of  service  and/or  command  and  control  support  required  during  a  mission.  This 
requirement  is  specified  in  terms  of  discrete  host  responsibility  alternatives  (e.g.  dedicated 
platform,  remote  command  and  control,  none,  etc.) 

Communication 

The  Communication  MOE  represents  the  system’s  capability  to  receive  and/ or  transmit  mission- 
related  information  from/to  a  host.  The  Communication  MOE  is  broken  down  into  two  sub¬ 
ordinate  MOE:  Reporting  Frequency  and  Data  Type.  Reporting  frequency  describes  the  fre¬ 
quency  of  transmissions  (e.g.  number  of  transmission  occurrences  per  hour)  from  system  to 
host  or  vice  versa.  Data  type  reflects  the  type  of  information  being  conveyed,  particularly  re¬ 
ferring  to  whether  it  is  “low  content”  or  “high  content”  data.  Low  content  data  would  include 
CAD/CAC8,  system  position/status,  contact  positions,  as  well  as  command  and  control-related 
information  from  a  host.  High  content  data  would  be  post-processed  data  intended  for  human 
interpretation,  such  as  sonar  imagery  or  “snippets”. 

7  If  determined  by  post-analysis  or  simulation,  localization  error  could  be  given  as  Distance  Root  Mean  Squared 
(DRMS). 

8  CAD/CAC  stands  for  computer-aided  detection/classification  and  refers  to  the  type  of  data  being 
transmitted. 
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Covertness 


The  Covertness  MOE  represents  the  extent  to  which  the  system’s  presence  and  efforts  are 
difficult  to  detect.  The  sub-MOE  partition  this  MOE  into  three  phases:  deployment,  mission, 
and  recovery.  Each  sub-MOE  represents  the  ability  of  the  system  to  avoid  detection  during 
that  particular  phase. 

3.4.4  MOE  Weights 

The  relative  weight  assigned  to  each  MOE  and  sub-MOE  should  reflect  the  preferences  of  the 
warfighter  in  relation  to  the  mission  and  the  specific  scenario  in  play.  While  the  warfighter  may 
understand  the  mission  very  well  and  have  a  feeling  of  which  system  operational  capabilities  are 
more  important  than  others,  converting  these  subjective  “values”  into  numeric  weights  is  often 
difficult.  The  Analytical  Hierarchy  Process  (AHP)  provides  a  useful  approach  for  attempting 
to  establish  the  correct  priorities  among  decision  criteria.  The  method  for  establishing  the 
Effectiveness  Model  MOE  weights  employs  an  AHP  pairwise  comparison  technique,  whereby 
the  criteria  are  directly  compared  to  each  other  (one  pair  at  a  time).  These  direct  comparison 
results  are  then  organized  into  matrix  form,  and  the  actual  relative  weights  are  determined  from 
the  matrix  eigenvector  corresponding  to  the  largest  eigenvalue  [14] .  The  weighting  technique  is 
illustrated  below  for  the  five  Effectiveness  Model  MOE. 

The  first  step  is  to  order  the  MOE  by  relative  importance  for  the  given  mission  scenario. 
Recall  that  it  is  the  warfighter  whose  preference  structure  should  be  extracted,  either  through 
surveys  or  other  direct  assessment  means.  For  a  typical  MCM  operation,  the  Mission  Time 
and  Mission  Accomplishment  will  be  regarded  as  the  most  critical  parameters,  forming  the 
classic  MCM  trade-off  between  timely  access  to  (or  simply  information  about)  a  suspected 
problem  area  versus  the  acceptable  risks  in  terms  of  loss  of  life,  loss  of  capital  assets,  and/or 
loss  of  tactical  advantage.  The  specific  mission  objectives  for  a  given  scenario  will  determine 
how  Mission  Time  and  Mission  Accomplishment  are  weighted  relative  to  each  other.  The 
Autonomy,  Communication,  and  Covertness  MOE  will  probably  be  weighted  on  a  second  tier  of 
importance,  but  still  must  be  compared  to  the  first  two.  Whatever  the  case,  the  ordering  of  the 
MOE  simplifies  the  process  of  assigning  importance  values  during  the  pairwise  comparison.  For 
this  example,  the  order  is  said  to  be  Mission  Time,  Mission  Accomplishment,  Communication, 
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Autonomy,  and  Covertness. 

Next,  each  MOE  is  compared  to  the  other  MOE  in  turn.  This  can  either  be  done  for  all  com¬ 
binations  of  MOE  pairs,  or  just  the  first  round  of  comparisons,  i.e.  comparing  one  MOE  to  each 
of  the  others  and  then  stopping.  The  AHP  process  emphasizes  the  former  approach  because 
it  tends  to  more  effectively  remove  bias  from  the  exercise  by  providing  multiple,  overlapping 
opportunities  to  assign  relative  importance.  After  the  eigenvalue  problem  is  solved,  a  math¬ 
ematical  check  ensures  that  enough  consistency  exists  in  the  pairwise  weights.  However,  the 
full  comparison  approach  can  be  time  consuming.  Beside  the  number  of  combinations  required, 
the  process  may  have  to  be  repeated  (with  revised  survey  questions  or  clarification  of  some 
sort)  in  order  to  get  the  necessary  consistency9.  The  second  approach  is  faster,  requiring  just 
n-1  comparisons  and  resulting  in  a  perfectly  consistent  matrix;  however,  the  resulting  weights 
may  not  reflect  the  warfighter’s  preference  structure  as  accurately  as  if  all  possible  pairwise 
comparisons  were  made.  Following  the  latter  approach  for  this  example,  the  MOE  are  assigned 
comparison  values  using  Time  as  the  reference  MOE.  The  subscripts  of  the  relative  importance 
values,  Rlij,  should  be  read  as  “the  relative  importance  of  i  over  j”,  where  i  and  j  correspond 
to  the  order  of  the  MOE.  Time  is  one,  Accomplishment  is  two,  and  so  forth. 


Time  vs  Accomplishment 
Time  vs  Communication 
Time  vs  Autonomy 
Time  vs  Covertness 


RIn  =  1.5 
RIu  =  4 
RI14  —  6 

Rhs  =  8 


The  remaining  RI  values,  representing  the  other  six  possible  MOE  pairs,  are  determined  by 
taking  ratios  of  the  first  four  (if  they  are  not  obtained  through  direct  comparison  as  described 
above).  For  example: 


Accomplishment  vs  Communication 


RI23  = 


RI13 

RIu 


RI23  =  2.667 


Setting  up  the  eigenvalue  problem,  whose  solution  will  yield  the  desired  MOE  weights,  the 
Rlij  values  are  placed  in  upper  triangular  section  of  a  square  matrix  with  columns  and  rows 

9  The  number  of  possible  pairwise  comparisons  is  n(n— 1)/2,  where  n  is  the  number  of  criteria.  The  consistency 
of  the  comparisons  is  measured  by  a  parameter  called  the  ’’inconsistency  ratio  ,  which  should  be  less  than  a 
specified  value  [17].  Refer  to  Appendix  C  for  detailed  calculations. 
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representing  the  five  MOE  in  the  previously  established  order.  Due  to  the  symmetric  properties 
of  the  matrix,  the  lower  triangular  elements  are  just  the  reciprocals  of  the  corresponding  upper 
half  elements. 


(  1  1.5  4  6  8  ^ 


0.667 

1 

2.667 

4 

5.333 

0.25 

0.375 

1 

1.5 

2 

0.167 

0.25 

0.667 

1 

1.333 

^0.125 

0.188 

0.5 

0.75 

1  J 

Once  the  matrix  is  fully  populated,  the  eigenvalue  problem  is  solved  (see  Appendix  C  for 
details  of  the  matrix  solution).  The  normalized  eigenvector  associated  with  the  maximum 
eigenvalue  of  the  matrix  contains  the  MOE  weights  of  interest: 


MOEwt  = 


^0.453^ 
0.302 
0.113  ■ 
0.075 
^0.057 j 


The  AHP  weighting  method  illustrated  here  can  be  used  for  establishing  the  relative  weights 
on  each  level  of  the  MOE  hierarchy.  In  the  Effectiveness  Model,  only  the  upper-level  MOE  were 
weighted  by  this  method.  The  sub-MOE  weights  are  entered  directly,  since  there  are  no  more 
than  three  to  compare  in  each  case. 


3.5  System  Model 

3.5.1  Overview 

Recall  the  two  main  purposes  of  the  system  model  within  the  evaluation  framework:  (1)  to  pro¬ 
vide  an  environment  in  which  to  design/configure  a  notional  AUV  system  and  (2)  to  determine 
the  system  MOP  required  as  input  to  the  Effectiveness  Model.  A  system  model  could  take  many 
forms  and  serve  many  additional  purposes,  as  long  as  it  meets  these  basic  requirements.  For 
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this  thesis,  in  keeping  with  the  primary  objective  of  evaluating  “advanced  search  concepts  for 
multiple- AUV  MCM,”  the  system  model  was  constructed  according  to  the  following  philosophy. 

The  absolute  minimum  requirements  for  the  model  would  be  to  meet  the  two  above-stated 
requirements  of  the  evaluation  framework  and  to  incorporate,  to  some  extent,  the  capability 
to  handle  multi- AUV  system  concepts.  To  aid  in  completing  the  model  within  the  available 
timeframe,  the  operational  requirements  for  the  system  would  be  limited  to  mine  reconnaissance 
(searching  and  mapping),  as  opposed  to  mine  clearance,  and  operational  scenarios  and  tactics 
would  be  kept  relatively  simple.  To  reduce  the  burden  on  the  user  and  facilitate  rapid  system 
definition,  the  model’s  input  requirements  would  be  kept  to  a  minimum  by  providing  databases 
of  vehicle  sub-system  components  whose  physical  and  performance  characteristics  are  relatively 
well-understood.  Finally,  time  permitting,  the  model  would  be  scoped  so  as  to  allow  evaluation 
of  a  broad  range  of  AUV  system  concepts.  At  the  low-capability  end,  this  would  include 
single-vehicle  concepts,  primarily  for  comparison  reasons.  At  the  high  end,  the  model  would 
handle  “cooperative”  multi- vehicle  concepts,  where  the  presence  of  multiple  vehicles  serves  to 
significantly  enhance  the  overall  capabilities  (and  hopefully  the  cost-effectiveness)  of  the  system. 

It  is  important  to  emphasize  that,  for  this  thesis,  the  System  Model  is  not  intended  to 
accurately  represent  the  physical  or  performance  characteristics  of  the  systems,  but  rather  to 
provide  consistent  representation  of  the  systems  so  that  they  can  be  evaluated  in  a  relative 
sense.  For  real-world  applications  of  the  evaluation  framework,  consistency  in  the  model  will 
still  be  vital,  and  accuracy  requirements  for  the  system  model  will  depend  on  the  particular 
evaluation  problem. 

3.5.2  System  Model  Components 

The  AUV  System  Model,  illustrated  in  Figure  3-5,  consists  of  three  modules:  Input  Mod¬ 
ule,  Mission  Planning  Module,  and  AUV  Design  Module.  Within  the  Input  Module,  the  user 
specifies  the  scenario  and  tactical  parameters  for  the  mission,  as  well  as  the  AUV  system  con¬ 
figuration  and  general  characteristics.  System  configuration  is  entered  in  terms  of  the  core 
mission-enabling  sub-components  for  each  type  of  vehicle.  These  sub-components,  referred  to 
as  payload,  include  sensors,  navigation  units,  and  communications.  The  user  also  specifies  the 
number  of  each  type  of  vehicle,  e.g.  one  Type  A  and  five  Type  B. 
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Figure  3-5:  AUV  System  Model 

The  parameters  required  by  the  Input  Module  are  listed  in  Table  3.1.  The  inputs  are  grouped 
into  three  categories:  scenario,  system  definition,  and  tactical  parameters.  For  an  evaluation 
exercise,  the  scenario  parameters  are  set  and  left  constant  while  the  system  definition  and 
tactical  parameters  are  specified  for  each  system  alternative.  Once  the  user  has  completed  the 
initial  data  entry,  certain  information  routes  from  the  Input  Module  directly  to  the  Effectiveness 
Model,  while  the  remaining  data  is  passed  to  the  Mission  Planning  Module  and  AUV  Design 
Module  for  further  processing. 

The  Mission  Planning  Module  performs  calculations  pertaining  to  the  MCM  mission  to 
reveal  what  is  required  of  the  system  in  order  to  meet  the  mission  objectives.  Specifically, 
the  module  determines  the  level  of  effort  required  by  the  system  to  achieve  the  user-specified 
MCM  objectives.  For  example,  if  the  user  desires  a  percent  search  of  90%  for  a  given  area,  the 
module  will  determine  the  number  of  tracks  that  the  AUV  system  must  run  in  order  to  achieve 
90%.  The  number  of  tracks  is  a  critical  parameter  for  determining  the  overall  mission  time. 
Mission  time  is  the  total  time  required  for  the  system  to  complete  the  entire  mission,  and  is 
also  calculated  in  the  Mission  Planning  Module.  It  includes  the  time  required  to  run  tracks, 
prosecute  contacts,  surface  for  navigation  or  communication  (if  required),  and  transit  to  and 
from  the  search  area.  The  effective  area  coverage  rate,  which  is  equal  to  the  total  search  area 
divided  by  the  total  mission  time,  is  also  provided  by  the  module.  Since  the  number  of  tracks 
is  an  integer,  the  predicted  percent  search  that  will  be  achieved  will  be  slightly  greater  than 
the  objective  value,  so  the  achieved  percent  search  is  given  as  an  output  of  the  module  as  well. 
The  inputs  and  outputs  for  the  Mission  Planning  Module  are  shown  in  Figure  3-6. 

It  is  worth  pointing  out  that  the  outputs  of  the  Mission  Planning  Module  are  actually  MOE 
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■■■ 

Mission  Objectives 

System-level  Requirements 

Speed 

Percent  search 

Number  of  vehicle  types 

Search  speed 

Transit  distances 

Host-system  comms  method 

Transit  speed 

Transit  distances 

Reporting  frequency 

Search  Parameters 

Environment 

System  navigation  fix  method 

Vehicle  altitudes 

Bottom  type  category 

Contact  position  error  threshold 

Number  of  runs/track 

Average  water  depth 

Reliability/redundancy  level 

Sonar  Performance  Parameters 

Mine  Threat 

Battery  recharge  method 

Characteristic  search  width 

Fraction  of  undetectable  mines 

Delivery  method  for  clandestine  ops 

Characteristic  probability  of  detect/class 

Assumed  mine  target  strength 

Recovery  method  for  clandestine  ops 

Probability  of  identification 

Estimated  number  of  mines 

Vehicle  Requirements  and  Payload 

Navigation  Performance 

Vehicle  type/role 

Position  error 

Number  of  vehicles  (each  type) 

Surfacing  requirement  (toggle) 

Maximum  vehicle  length 

Maximum  vehicle  diameter 

Maximum  vehicle  deadweight 

Sonar  type(s) 

Navigation  package 

Communication  package 

Computer/processor 

Battery  type 

Standard  deviation  of  track  keeping 

Table  3.1:  Input  Module  Parameters 


Percent  search  desired 
Search  area 
Transit  distances 
Search  speed 
Transit  speed 
Sensor  swaths 
Sensor  detection  probs 
Track  deviation 


Mission  Planning 
Module 


Mission  time 

Percent  search  achieved 


Figure  3-6:  Mission  Planning  Module  Inputs  and  Outputs 
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that  have  been  determined  through  modeling  (as  opposed  to  direct  assessment),  taking  into 
account  certain  mission  parameters.  Admittedly,  the  inclusion  of  mission-oriented  calculations 
in  the  system  model  is  a  deviation  from  the  originally-stated  approach.  The  reason  for  this 
deviation  is  to  maintain  consistency  between  the  systems  being  evaluated  by  requiring  some 
of  the  system  parameters  to  be  specified  as  objectives  and  to  apply  those  objectives  to  all  the 
systems  being  considered.  This  constrains  the  problem  somewhat,  forcing  the  values  of  certain 
parameters  for  each  system  to  comply  with  the  desired  common  objectives.  As  shown  in  Table 
3-6,  the  user-specified  objectives  for  this  model  are  percent  search,  search  area,  and  transit 
distances.  The  System  Model  combines  the  given  values  with  internally  calculated  time  results 
to  arrive  at  the  total  mission  time.  Mission  time  is  then  used  as  a  reference  for  the  endurance 
of  the  multi- AUV  system,  and  therefore  the  endurance  of  each  AUV  within  the  system.  The 
endurance  of  the  system  is  fixed  in  this  manner  so  that  all  systems  being  compared  can  be  said 
to  have  just  enough  endurance  to  complete  the  mission  (with  some  uniform  margin  built  in,  if 
desired). 

The  AUV  Design  Module  designs  the  individual  AUVs  based  on  the  user-specified  pay- 
load  items  and  the  results  of  the  Mission  Planning  Module.  This  is  done  primarily  to  provide 
a  reasonable  estimate  of  vehicle  sizes  required  to  accommodate  the  payloads  and  meet  the 
endurance  requirement.  The  AUV  Design  Module  was  developed  by  modifying  a  parametric- 
based  submarine  design  model*®  currently  used  at  MIT.  The  AUV  version  of  the  model  performs 
three  main  engineering  “balances” :  volume  required  versus  available,  weight  versus  buoyancy, 
and  speed  versus  power.  For  the  volume  balance,  the  module  allows  the  user  to  adjust  the 
vehicles  dimensions  and  shape,  essentially  wrapping  a  shell  around  the  payload  components 
(sensor /navigation/communication/computer  packages  and  battery),  until  the  available  vol¬ 
ume  / displacement  meets  or  exceeds  that  which  is  required.  Vehicle  weights  are  then  estimated, 
and  ballast  requirements  are  calculated  to  achieve  a  desired  buoyancy  condition.  For  powering, 
the  Module  performs  resistance  calculations  to  determine  the  amount  of  energy  (i.e.  battery 
size/weight)  required  to  meet  the  specified  speed  and  endurance  for  the  mission.  The  user 

10  The  MIT  SSN  (attack  submarine)  Math  Model  is  a  Mathcad-based  tool  used  for  design  courses  in  the  Naval 
Construction  and  Engineering  Program  (13A).  The  original  model,  developed  in  1995,  was  based  on  design 
parametrics  developed  by  CAPT  Harry  Jackson,  USN  (Ret).  The  model  has  been  updated  by  students  and 
faculty  over  the  last  several  years.  The  AUV  version  of  the  follows  the  general  procedure  of  the  SSN  Model,  but 
is  greatly  simplified  and  uses  only  a  few  of  the  same  parametric  relationships. 
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Figure  3-7:  AUV  Design  Module  Inputs  and  Outputs 

iterates  through  the  model  to  achieve  an  overall  balance.  Figure  3-7  summarizes  the  inputs  and 
outputs  for  the  AUV  Design  Module. 

3.5.3  System  Model  MOP 

For  an  AUV  system  modeled  as  described  in  the  preceding  paragraphs,  the  MOP  should  include 
all  of  the  highest-level  system  physical  and  performance  characteristics.  As  alluded  to  in  the 
discussion  of  the  Mission  Planning  Module,  it  is  sometimes  difficult  to  sort  out  the  MOE  and 
MOP,  especially  when  the  MOE  are  determined  through  modeling  rather  than  utility  functions. 
For  this  thesis,  the  rule-of-thumb  for  distinguishing  between  MOE  and  MOP  has  been  to  ask 
whether  or  not  the  parameter  is  purely  system-dependent,  or  whether  it  depends  on  external, 
mission-related  factors.  In  keeping  with  this,  the  MOP  corresponding  to  each  MOE  were 
identified.  Table  3.2  summarizes  the  MOP  for  each  sub-MOE. 


3.6  The  Integrated  AUV  MCM  System  Evaluation  Model 

Bringing  the  System  Model  and  Effectiveness  Model  together  forms  the  Integrated  AUV  MCM 
System  Evaluation  Model.  This  framework  permits  the  evaluation  of  notional  AUV  MCM  sys¬ 
tems  in  the  context  of  overall  mission-effectiveness.  Incorporating  cost,  the  mission-effectiveness 
of  the  systems  are  weighed  against  the  costs  that  are  considered  paramount,  providing  a  firm 
basis  for  decision-making.  Figure  3-8  illustrates  the  Integrated  AUV  MCM  System  Evaluation 
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MOE  (Subordinates) 

MOP 

Effective  Coverage  Rate 

Search  Speed  (knots) 

Transit  Speed  (knots) 

Search  Level 

Characteristic  search  width  (yards) 

Characteristic  probability  of  detection/classification  (percent) 

Probability  of  identification  (percent) 

Standard  deviation  of  track  keeping  (yards) 

Localization  Accuracy 

Navigation  position  error  (%  distance  traveled) 

Lift  Support 

System  footprint  (sqft) 

Host  Support 

Platform  requirement  (levels) 

Reporting  Frequency 

Reporting  opportunities  (levels) 

Data  Type 

Data  content  (levels) 

Deployment  Phase 

Platform  type  (levels) 

Mission  Phase 

Platform  type  and  standoff  distance  (levels) 

Recovery  Phase 

Platform  type  (levels) 

Table  3.2:  System  Model  MOP  Corresponding  to  Effectiveness  Model  MOE 


Model. 

3.6.1  MOE-MOP  Relationships 

The  critical  aspect  of  the  Evaluation  Model  is  the  link  between  the  MOE  and  MOP.  Section 
3.2  discussed  two  general  methods  for  determining  MOE  from  MOP:  modeling/ simulation  and 
direct  assessment.  For  each  MOE,  the  choice  of  translation  method  depends  not  only  on  the 
type  of  information  that  is  available  from  the  system  model,  but  whether  a  non-sub jective 
relationship  between  the  system  parameters  and  the  MOE  can  be  determined.  If  such  a  valid 
relationship  can  be  established  with  a  reasonable  amount  of  effort,  then  modeling/simulation 
is  the  best  choice.  If  not,  a  general  (subjective)  relationship,  derived  from  direct  assessment  of 
the  warfighter *s  preferences,  should  be  used.  The  Evaluation  Model  MOE-MOP  relationships 
were  forged  according  to  these  criteria.  Table  3.3  summarizes  the  method  of  translation  for 
each  MOE-MOP  set  and  lists,  in  the  fourth  column,  the  primary  mission-related  parameters 
and  considerations  that  contribute  to  the  relationships.  In  following  subsections,  the  MOE- 
MOP  relationships  are  presented.  It  is  emphasized  that  the  subjective  relationships  must  be 
based  on  the  warfighter’s  preferences  in  order  to  be  valid.  For  this  thesis,  no  surveys  or  other 
means  of  assessment  were  conducted.  For  all  subjective  MOE-MOP  relationships,  the  MOE 
scores  corresponding  to  the  MOP  inputs  were  assigned  by  the  author  and  are  meant  to  be 
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Figure  3-8:  Integrated  AUV  MCM  System  Evaluation  Model 
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Sub-MOE 

MOP 

MOE-MOP  Transla¬ 
tion 

Mission  Parameters 

Effective  Coverage  Rate 

Search  Speed  (knots) 

Modeling 

Search  area 

Transit  Speed  (knots) 

Number  of  tracks 

Est.  number  of  mines 

Search  Level 

Characteristic  search  width  (yards) 

Modeling 

Target  strength 

Characteristic  probability  of  detec¬ 
tion/classification  (percent) 

Bottom  type 

Probability  of  identification  (per¬ 
cent) 

Sonar  parameters 

Standard  deviation  of  track  keeping 
(yards) 

Water  depth 

Localization  Accuracy 

Navigation  position  error  (%  dis¬ 
tance  traveled) 

Modeling 

Contact  position  error  threshold 

Lift  Support 

System  footprint  (sqft) 

Modeling 

Space  restrictions;  impact  on 
other  missions 

Host  Support 

Platform  requirement  (levels) 

Subjective  relationship 

Impact  of  host  reqmt  on  other 
mission 

Reporting  Frequency 

Reporting  opportunities  (levels) 

Subjective  relationship 

Degree  of  need  for  host-system 
communication 

Data  Type 

Data  content  (levels) 

Subjective  relationship 

Degree  of  need  for  certain  infor¬ 
mation  types/formats 

Deployment  Phase 

Platform  type  (levels) 

Subjective  relationship 

Mission  Phase 

Platform  type  and  standoff  distance 
(levels) 

Subjective  relationship 

Desire  to  avoid  detection 

Recovery  Phase 

Platform  type  (levels) 

Subjective  relationship 

Desire  to  avoid  detection 

Table  3.3:  MOE-MOP  Translation  Summary 


representative  only. 


MOE-MOP  Relationships  for  Mission  Time 

Effective  Area  Coverage  Rate  is  the  sub-MOE  used  to  describe  the  Mission  Time  MOE.  It  is 
equal  to  the  search  area  divided  by  the  total  mission  time.  Total  mission  time  is  determined 
from  the  system’s  speed  and  associated  distance  traveled  during  each  segment  of  the  operation. 
For  this  model,  the  time  segments  are:  transit  time,  search  time,  navigation/ communication 
excursion  time,  and  prosecution  time.  Equation  3.1  applies. 


ACReff  = 


L searcharea  '  ^^searcharea 


Tmission 


where, 

ACReff  =  Effective  area  coverage  rate 


(3.1) 


40 


Lsearcharea  '  W sear  chorea  —  Search  area. 


Tmissicm  —  Total  mission  time 

The  individual  time  calculations  must  be  tailored  to  the  type  of  operation  being  conducted, 
as  well  as  the  tactics  employed.  The  details  of  these  calculations  for  the  Evaluation  Model  can 
be  found  in  Appendix  C.  The  source  of  Equation  3.1  is  reference  [15]. 

MOE-MOP  Relationships  for  Mission  Accomplishment 

For  the  minehunting  problem,  the  Mission  Accomplishment  MOE  receives  its  score  from  the 
Search  Level  and  Localization  Accuracy  sub-MOE.  The  selected  approach  for  predicting  Search 
Level,  or  percent  search,  is  based  on  an  “approximation  theory”  developed  by  the  Navy  in 
the  1960s.  This  approach,  outlined  in  PEO(MIW)  Instruction  3370  [15],  remains  the  standard 
method  for  estimating  search  and/or  clearance  levels  for  U.S.  Navy  MCM  operations.  It  applies 
to  uniform  coverage  over  a  set  of  parallel  tracks.  The  governing  relationships,  as  applied  to 
the  minehunting  problem  for  this  thesis,  are  summarized  as  follows.  The  equation  for  percent 
search  is: 


Psearch  —  (1  A1)  '  Pimm  *  (1  e  ) 


(3.2) 


where, 

Psearch  =  Percent  search  through  identification 

/x  =  Fraction  of  undetectable  mines 

Ptmm  =  Probability  of  identifying  a  mine  as  a  mine 

M  =  h— =  Combined  measure  of  area  coverage  level  and  detect/ class  success 

J  =  Number  of  runs  per  track 

A  =  Sensor  characteristic  search  width 

D  —  Characteristic  probability  of  detection/ classification 

Dtrack  —  Distance  between  tracks 

Y  =  •  /  ln[l  -  B  ■  ( cnorm(u  +  -  ( cnorm{u  -  £))]du 

o 

Y  =  Coefficient  of  MCM  efficiency 
a  =  Standard  deviation  of  track  keeping  error 
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cnorm(x)  =  Value  of  the  cumulative  normal  distribution  function  at  x 

Localization  Accuracy  is  determined  in  a  much  more  straight-forward  manner.  A  general 
assumption  is  made  that  the  AUV  MCM  system  will  have  some  means  of  fixing  its  position 
periodically  in  order  to  navigate  along  the  intended  tracks.  The  System  Model  requires  an 
entry  for  the  maximum  acceptable  contact  position  error  at  any  point  during  the  search  effort. 
Ignoring  any  error  due  to  the  sensor,  and  assuming  further  that  the  position  error  of  the  AUV 
grows  linearly  with  time  (i.e.  as  a  percentage  of  distance  traveled),  the  average  contact  position 
error  over  the  course  of  the  search  should  be  approximately  one  half  of  the  maximum  position 
error: 

avg _pos _error  =  0.5  *  max _pos _error  (3-3) 

MOE-MOP  Relationships  for  Autonomy 

The  sub-MOE  for  Autonomy  are  Lift  Support  and  Host  Support.  Because  Lift  Support  refers 
to  the  inconvenience  or  other  costs  associated  with  transporting  the  AUV  system  to/from  the 
mission  area,  a  reasonable  metric  is  the  system  cargo  area  requirement,  or  footprint.  The 
footprint  is  determined  from  Equation  3.4: 

numtype 

FPsys  =  fstowi-numvehi-FPvehi  (3-4) 

i=l 

where, 

FPSys  —  Total  AUV  system  footprint,  or  required  cargo  area 

numtype  =  Number  of  vehicle  types  in  system 

fstowi  =  Stowage  factor  (fraction  multiplier)  for  vehicle  type  i 

numvehi  =  Number  of  vehicles  of  the  ith  type 

FPvehi  =  Footprint  of  ith  vehicle  type 

Host  Support  is  meant  to  reflect  the  level  of  service  and/or  command  and  control  sup¬ 
port  required  during  a  mission.  This  sub-MOE,  and  in  fact  all  of  the  remaining  sub-MOE, 
are  governed  by  completely  subjective  relationships  as  opposed  to  mathematical  formulas.  For 
example,  Host  Support  is  specified  in  terms  of  discrete  host  responsibility  alternatives:  dedi- 
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cated  platform,  remote  command  and  control,  and  none  required.  Presumably,  these  levels  of 
support  have  definite  meaning  to  the  warfighter,  with  “none  required”  being  the  ideal  case  and 
“dedicated  platform”  the  worst.  To  figure  out  which  case  applies  to  the  particular  AUV  system 
being  evaluated,  condition  statements  are  used.  The  conditions  are  specific  system  characteris¬ 
tics  that  would  cause  a  certain  type  of  support  to  be  required.  In  the  Effectiveness  Model,  these 
conditional  statements  are  written  in  terms  of  system  parameters  whose  “values”  are  discrete 
designators,  each  of  which  represents  a  system  characteristic.  For  all  of  the  sub-MOE,  these 
characteristics  are  specified  as  inputs,  during  system  definition,  so  that  the  possible  outcomes 
are  set  in  advance.  Table  3.4  lists  the  conditions  that  determine  each  level  of  the  Host  Support 
sub-MOE. 


Host  Support  Level 

Condition(s) 

Dedicated  or  in-theater  support 

Reliability  =  “low”  OR 

Communications  method  —  “acoustic  modem”  OR 
Communications  method  =  “RF  line  of  sight”  OR 
Battery  recharge  method  =  “host” 

Remote  command  and  control 

Communications  method  =  “RF  via  satellite” 

None  required 

Otherwise 

Table  3.4:  Conditions  for  Determining  Host  Support  MOE  Levels 


MOE-MOP  Relationships  for  Communication 

The  two  sub-MOE  for  Communication,  pertaining  to  how  often  communication  occurs  and 
how  valuable  the  data  is,  are  determined  from  system-level  requirements  specified  in  the  Input 
Module.  Tables  3.5  and  3.6  present  the  levels  and  conditions  for  Reporting  Frequency  and  Data 
Type,  respectively. 


Reporting  Frequency  Level 

Condition(s) 

None 

Reporting  frequency  =  “not  required” 

Periodic 

Communications  method  =  “periodic” 

Continuous 

Otherwise 

Table  3.5:  Conditions  for  Determining  Reporting  Frequency  MOE  Levels 
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Data  Type  Level 

Condition(s) 

None 

Communications  method  =  “none  required” 

Low-content  data 

Communications  method  —  “acoustic  modem” 

High-content  data 

Otherwise 

Table  3.6:  Conditions  for  Determining  Data  Type  MOE  Levels 


MOE-MOP  Relationships  for  Covertness 

For  Covertness,  the  sub-MOE  represent  the  likelihood  of  avoiding  detection  during  any  of  three 
operational  phases:  Deployment  Phase,  Mission  Phase,  Recovery  Phase.  The  ability  of  an  AUV 
system  to  avoid  detection  will  depend  on  many  factors,  including  signatures  (e.g.  magnetic, 
acoustic,  radar  cross-section,  etc.)  and  time  spent  in  the  area  of  concern.  These  factors  apply 
not  only  to  the  AUV  system,  but  also  to  its  host  platform,  if  applicable.  To  develop  concise 
relationships  for  these  sub-MOE,  the  problem  was  simplified  by  linking  the  level  of  covertness  to 
the  type  of  host  platform  required  to  support  the  AUV  system  during  each  of  the  three  mission 
phases.  In  the  case  of  the  Mission  Phase  sub-MOE,  the  location  of  the  platform  (i.e.  the 
proximity  to  the  area  of  concern)  is  also  factored  in.  This  simplification  assumes  a  significant 
relative  difference  between  the  signatures  of  the  AUV  system  and  the  host  platform.  Three 
platform  types  are  used  in  the  relationships:  surface,  sub-surface,  and  air.  For  Mission  Phase, 
the  relationship  is  modified  slightly  so  that  it  corresponds  to  the  type  of  host  platform  required 
for  the  search.  Tables  3.7  through  3.9  show  the  relationships. 


Delivery  Phase  Level 

Condition(s) 

Surface  ship 

Delivery  method  =  “surf” 

Aircraft 

Delivery  method  =  “air” 

Submarine 

Delivery  method  =  “sub” 

None  required 

Delivery  method  =  “not  required” 

Table  3.7:  Conditions  for  Determining  Delivery  Phase  MOE  Levels 


3.6.2  MOE  Scoring  and  Interpretation 

Having  established  all  MOE-MOP  relationships  for  the  Evaluation  Model,  the  final  task  in 
the  model’s  development  is  to  ensure  the  MOE  are  presented  in  a  useful  manner.  Using  the 
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Mission  Phase  Level 

Condition(s) 

Surface  ship 

Otherwise  (none  of  the  below 
conditions) 

Submarine 

Delivery  method  =  ”sub” 

Satellite/air  link 

Host  Support  Level  =  NOT 
”  none  required”  AND  NOT 
”  dedicated/in- theater  support” 

None  required 

Host  Support  Level  —  ”none  re¬ 
quired” 

Table  3.8:  Conditions  for  Determining  Mission  Phase  MOE  Levels 


Recovery  Phase  Level 

Condition(s) 

Surface  ship 

Delivery  method  —  “surf” 

Aircraft 

Delivery  method  =  “air” 

Submarine 

Delivery  method  =  “sub” 

None  required 

Delivery  method  =  “not  required” 

Table  3.9:  Conditions  for  Determining  Recovery  Phase  MOE  Levels 

MOE  results  obtained  above,  comparison  of  even  a  small  number  of  systems  would  be  difficult 
because  of  the  variation  in  the  way  the  MOE  “values”  are  stated.  Effective  Coverage  Rate, 
Search  Level,  Localization  Accuracy,  and  Lift  Support  have  real  numeric  values  with  associated 
units.  The  others  are  given  as  levels  of  capability  or  action  that  contribute  to  the  mission. 
In  many  cases,  a  uniform  scale  of  measure  is  desirable  for  comparison  of  sub-MOE  between 
systems.  Furthermore,  such  a  scale  is  required  in  order  to  incorporate  the  MOE  and  sub-MOE 
weights.  This,  after  all,  is  the  main  purpose  of  the  effectiveness  hierarchy  (recall  Figure  3-4). 
Still,  for  some  comparisons,  a  mix  of  scaled  and  real  values  may  be  useful,  as  shown  in  the  case 
demonstrations  (Chapter  4). 

A  simple  means  of  scaling  a  parameter  is  to  establish  lower  and  upper  bounds,  assign  them  a 
score  of  0  and  1,  respectively,  and  then  determine  how  the  intermediate  values  of  the  parameter 
are  scored  on  that  scale.  The  result  is  a  utility  function  which  translates  the  original  parameter 
value  into  a  score  between  0  and  1.  If  linear  scaling  is  appropriate,  the  score  for  any  intermediate 
value  is  determined  by  Equation  3.5: 


ScaledV alued  —  (intermediate jvalue  —  low_value)/ ( high-value  —  low_value )  (3.5) 


For  situations  where  desired  output  does  not  vary  linearly  with  the  input,  a  non-linear 
utility  function  is  required.  While  not  used  in  the  Evaluation  Model,  one  formal  method  for 
determining  non-linear  relationships  is  mentioned  because  of  the  possible  applicability  to  fu¬ 
ture  developments  of  the  model.  The  technique  follows  the  AHP  pairwise  comparison  matrix 
procedure  used  to  establish  the  MOE  weights  (Section  3.4.4),  except  that  the  eigenvector  is 
scaled  according  to  Equation  3.5  (rather  than  normalized).  For  this  application,  the  row  and 
column  entries  correspond  to  selected  input  parameter  values  instead  of  MOE,  and  it  is  those 
input  values  whose  importance  is  compared  in  pairs  to  populate  the  matrix.  The  result  is  a 
piecewise-linear  utility  function  that  accounts  for  the  macroscopic  non-linearity  of  the  relation¬ 
ship,  but  is  linear  between  the  values  used  for  the  comparison.  Reference  [14]  provides  details 
on  this  approach. 

Getting  back  to  the  Evaluation  Model,  the  sub- MOE  are  scored  as  follows.  For  the  sub-MOE 
that  are  given  in  terms  of  levels,  scores  of  0  and  1  are  assigned  to  the  least  and  most  desirable 
levels,  respectively.  Because  there  are  only  a  few,  discrete  intermediate  levels  to  be  scored,  the 
scores  can  be  directly  assigned  according  to  the  warfighter’s  preferences.  For  these  sub-MOE, 
the  scores  are  built  into  the  MOE  calculations  because  the  named  levels  are  more  cumbersome 
for  comparison  purposes.  For  the  remaining  sub-MOE  —  those  with  real  values  initially  —  linear 
scaling  is  assumed,  but  not  applied  inside  the  Effectiveness  Model.  Instead,  this  is  done  in  a 
separate  spreadsheet,  using  Equation  3.5,  only  when  the  scores  are  to  be  multiplied  by  their 
associated  sub-MOE  weights  (see  end  of  Appendix  C). 

To  incorporate  the  MOE  weights,  the  appropriately  scaled  sub-MOE  are  multiplied  by  their 
individual  weights.  The  weighted  scores  under  each  MOE  are  then  summed,  and  the  five  MOE 
weighted  sums  are  added  to  obtain  the  overall  MOE  (OMOE).  This  single  score  now  represents 
the  entire  AUV  system  on  a  scale  of  0  to  1.  The  OMOE  scores  for  a  large  number  of  systems 
can  be  plotted  against  an  independent  parameter,  such  as  cost,  to  guide  the  evaluator (s)  toward 
a  decision  as  to  which  system  or  systems  exhibit  the  best  cost-effectiveness  mix. 
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3.6.3  Implementation  and  Use 

The  Evaluation  Model  is  implemented  in  a  series  of  worksheets  (i.e.  files)  residing  in  two 
computer  software  programs:  Mathcad11  and  Excel12.  The  files  are  linked  together  using  com¬ 
patibility  features  of  the  two  programs.  Nearly  all  of  the  analytical  calculations  are  performed 
by  Mathcad,  with  Excel  being  used  mostly  for  databasing,  user  entry,  and  graphical  display 
of  results.  Mathcad  was  selected  over  other  computing  programs/languages,  such  as  Matlab 
and  Fortran,  as  much  for  its  abilities  as  for  its  “what  you  see  is  what  you  get”  presentation 
attributes.  Equations,  text,  and  graphics  entered  in  the  worksheet  appear  very  much  like  you 
would  see  them  on  a  blackboard  or  in  a  textbook.  The  highly  visual  nature  of  the  model  is 
intended  to  facilitate  interpretation  and  understanding  of  the  model’s  underlying  methodology 
so  that  future  developments  and  extensions  of  the  evaluation  approach  are  not  hindered  by 
hard-to-follow  programming  codes.  Appendix  A  contains  a  summary  of  the  programmatic  de¬ 
tails  of  the  Evaluation  Model,  including  a  “wiring  diagram”  which  illustrates  how  the  various 
files  are  connected.  Appendices  B  and  C  contain  the  System  Model  and  Effectiveness  Model, 
respectively.  Appendix  D  contains  AUV  sub-system  databases  for  the  System  Model. 

Having  defined  and  presented  the  major  components  and  relationships  of  the  Evaluation 
Model,  a  more  practical  aspect  of  the  model  is  now  addressed:  its  use.  In  Section  3.3,  the 
evaluation  process  was  described  (reference  Figures  3-2  and  3-3).  Figure  3-8  in  Section  3.6 
summarizes  the  Evaluation  Model,  showing  the  connection  between  the  System  and  Effective¬ 
ness  Models.  Merging  the  evaluation  process  and  model  architecture  diagrams,  Figure  3-9 
illustrates  the  evaluation  process  in  the  context  of  the  modeling  environment.  Guided  by  this 
process,  a  typical  AUV  MCM  system  evaluation  problem  involves  defining  a  series  of  system 
concepts,  modeling  each  system  to  obtain  MOE  and  cost  results,  and  comparing  the  outcomes 
to  reach  a  conclusion  or  decision.  Chapter  4  further  discusses  the  use  of  the  Evaluation  Model 
and  the  application  of  the  evaluation  framework  as  a  whole. 


11  Mathcad  2000  Professional,  by  Mathsoft,  Inc. 

12  Microsoft  Excel  97,  by  Microsoft  Corporation. 
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Figure  3-9:  AUV  MCM  System  Evaluation  Flowchart 
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Chapter  4 


Case  Demonstrations 


The  primary  purpose  of  the  case  demonstrations  is  to  show,  through  simple  examples,  the 
basic  features  of  the  Evaluation  Model  and  the  manner  in  which  results  are  obtained.  The 
secondary  purpose  is  to  demonstrate  the  use  of  the  model  for  two  particular  types  of  evaluation 
problems.  In  observing  and  discussing  the  results,  the  emphasis  is  placed  on  the  nature  of 
the  outputs  (rather  than  the  actual  values)  and  how  they  can  assist  the  evaluator  in  reaching 
the  sought-after  decision  and/or  conclusions.  It  is  important  to  note  that,  for  both  cases,  the 
results  themselves  are  based  on  non-validated  technical  information  within  the  System  Model 
and  borrowed  cost  model,  and  so  should  be  thought  of  as  representative  only. 

4.1  Case  One 

4.1.1  Case  One  Definition 

The  first  case  compares  two  AUV  MCM  system  concepts  that  have  very  similar  system-level 
requirements  and  sub-system  components  (i.e.  sensor  types,  navigation  packages,  etc.),  but 
are  composed  and  configured  quite  differently.  Presumably,  the  evaluator  or  decision  maker 
is  interested  in  identifying  the  key  differences  between  each  system,  in  terms  of  mission  effec¬ 
tiveness,  and  then  weighing  those  differences  against  the  cost(s)  of  each  system.  This  type  of 
comparison  exercise  would  likely  be  conducted  by  designers  in  the  early  phase  of  an  AUV  MCM 
system  design,  perhaps  to  initially  scope  the  trade-space  or  to  down-select  among  a  set  of  broad 
concept  alternatives. 
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Mission  objectives 

Percent  Search 

94% 

Search  area  dimensions 

Length:  4  nautical  miles 
Width:  4000  yards 

Transit  distances 

Ingress:  0  nautical  miles 
Egress:  10  nautical  miles 

Environment 

Bottom  type  category 

4  (gravel) 

Average  water  depth 

400  feet 

Mine  threat 

Number  of  mines  (estimate) 

25 

Fraction  of  undetectable  mines 

0 

Mine  target  strength 

-30  decibels 

Table  4.1:  Case  One  Scenario  Inputs 


The  analysis  follows  the  procedure  depicted  in  Figure  3-3.  First,  a  fixed  scenario  is  devel¬ 
oped  for  the  evaluation  and  the  MOE  weights  established  for  that  scenario.  Next,  the  system 
concepts  are  defined  by  specifying  the  appropriate  parameters  for  each  system.  Once  the  sys¬ 
tem  definition  is  completed,  mission  planning  calculations  are  performed  to  determine  the  total 
mission  time  required  to  achieve  the  desired  search  objectives.  Each  AUV  type  is  then  designed 
to  carry  the  required  payload  components  and  meet  the  endurance  requirements  demanded  by 
the  mission  time  requirement.  From  the  system  characteristics,  the  effectiveness  and  cost  of 
each  are  determined  and  compared. 

The  case  scenario  is  based  on  a  mine  reconnaissance  mission  requiring  a  clandestine  search 
in  a  4  x  2  nautical  mile  area  near  the  coast  of  enemy-occupied  territory.  An  estimate  of  the 
number  of  mines  and  their  average  target  strength  is  obtained  through  intelligence  sources.  The 
bottom  type  is  known  to  be  gravel,  and  the  average  water  depth  in  the  area  is  400  feet.  The 
concept  of  operations  calls  for  the  AUV  system  to  be  air-dropped  adjacent  to  the  search  area, 
and  picked  up  via  surface  ship  after  the  mission  at  a  rendezvous  point  10  nautical  miles  from 
the  area.  Table  4.1  contains  the  input  values  for  the  scenario  parameters. 

For  this  scenario,  the  MOE  and  sub-MOE  weights  are  established  as  described  in  Section 
3.4.4.  Referring  to  Table  4.2,  the  imaginary  warfighter  (a  role  played  by  the  author  for  this 
case  demonstration)  regards  Time  and  Mission  Accomplishment  as  markedly  more  important 
than  the  other  three  upper-level  MOE.  The  relative  weightings  for  sub-MOE  reveal  that  certain 
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MOE 

MOE  Weight 

Sub-MOE 

Sub-MOE  Weight 

Time 

0.45 

Effective  Area  Coverage  Rate 

1.00 

Mission  Accomplishment 

0.30 

Search  Level 

0.60 

Localization  Accuracy 

0.40 

Autonomy 

0.08 

Lift  Support 

0.25 

Host  Support 

0.75 

Communication 

0.11 

Reporting  Frequency 

0.30 

Data  Type 

0.70 

Covertness 

0.06 

Deployment  Phase 

0.40 

Mission  Phase 

0.35 

Recovery  Phase 

0.25 

Table  4.2:  Case  One  MOE  Weights 


aspects  of  each  top-level  MOE  are  considered  more  important  than  others,  such  as  the  level  of 
host  support  over  lift  support  and  type  of  contact  data/information  over  the  frequency  of  the 
contact  reports. 

Two  AUV  MCM  system  concepts  are  evaluated.  System  One  (SI)  consists  of  a  single 
AUV  with  several  minehunting  sensors,  a  robust  navigation  package,  and  radio  frequency  (RF) 
satellite  communications  gear.  System  Two  consists  of  two  different  vehicle  types,  one  of  one 
type  and  two  of  the  other,  designed  to  operate  as  a  cohesive  unit.  For  the  most  part,  System 
Two  (S2)  contains  the  same  sensors,  navigation  units,  communications  gear,  and  other  AUV 
sub-systems  as  System  One.  In  this  case,  however,  these  sub-systems  are  distributed  between 
the  two  AUV  types.  Vehicle  Type  One  (VI)  is  designated  as  the  “guide”.  It  possesses  an 
ahead- looking  sonar  (ALS)  and  the  same  navigation  and  communication  packages  as  the  AUV 
in  SI.  It  operates  closer  to  the  surface  than  the  other  vehicles  in  S2,  allowing  it  to  surface 
regularly  for  GPS  fixes  and  RF  communication  without  incurring  the  significant  time  delays 
it  would  if  operating  at  a  deeper  depth.  Vehicle  Type  Two  (V2)  houses  a  side-scan  sonar  for 
mine  detection  and  classification,  as  well  as  a  small  video  camera  for  identification  (ID).  For 
navigation,  it  has  a  basic  gyro-compass  and  doppler  velocity  sensor  (DVS),  but  does  not  have 
the  capability  to  fix  its  position.  Instead,  it  relies  on  the  guide  (VI),  maintaining  station  relative 
to  VI  using  an  acoustic  tracking  system  similar  to  an  ultra-short  baseline  (USBL)  array.  The 
two  vehicles  of  this  type  operate  close  to  the  bottom,  at  the  optimum  depth  for  the  side-scan 
sonar,  relaying  contact  data  and  imagery  acoustically  to  the  lead  vehicle  (for  post-processing 
and  further  relay  to  the  host).  The  system- level  requirements/characteristics  for  SI  and  S2  are 
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identical,  except  for  the  number  of  vehicle  types,  of  course.  Table  4.3  summarizes  the  system 
definition. 

Table  4.4  displays  the  tactical  parameters  for  SI  and  S2.  The  sonar  performance  metrics 
for  minehunting  are  given  in  terms  of  characteristic  search  width,  A;  probability  of  detec¬ 
tion/classification,  B;  probability  of  identification;  and  false  contact  density  (for  classification) 
[15].  “A”  and  “B”  are  simplified  parameters  describing  the  effective  swath  of  a  sensor  (A) 
and  the  associated  joint  probability  of  mine  detection  and  classification  (B).  These  values  de¬ 
pend  on  parameters  like  sensor  altitude,  water  depth,  bottom  type,  and  mine  type.  Likewise, 
“A”  and  “B”  and  the  other  sensing  performance  parameters  are  affected  by  information  ex¬ 
change  between  sensors.  This  is  why,  for  S2,  the  side-scan  sonar  performance  values  are  slightly 
higher  than  for  the  same  sonar  in  the  case  of  SI.  S2  was  configured  so  as  to  achieve  increased 
performance  by  using  multiple,  cooperating  vehicles1 . 

The  inputs  in  Tables  4.1  through  4.4  were  entered  in  the  Input  Module  using  the  Mathcad- 
Excel  program  interface. 

4.1.2  Case  One  Results 

Following  the  entry  of  required  case  inputs,  Systems  One  and  Two  were  run  through  the  Eval¬ 
uation  Model  one  at  a  time.  Costs  for  each  system  were  estimated  using  the  costing  feature  of 
the  MCM  Future  Systems  Working  Group’s  UUV  Endurance  Model.  The  results  of  each  run 
were  collected  in  an  Excel  output  file  for  the  comparison.  Table  4.5  summarizes  the  results 
numerically. 

The  results  arc  a  mixture  of  real  values  (with  units)  and  non-dimensional  scores  (on  a  scale 
"of  0  to  1).  The  former  are  largely  the  products  of  modeling  to  obtain  MOE  from  MOP,  while 
the  latter  are  the  result  of  MOP-MOE  utility  functions.  Because  of  the  manner  in  which  the 
systems  were  defined,  many  of  the  parameters  achieve  the  same  h40E  scores.  The  interesting 
comparisons  are  found  in  the  effective  area  coverage  rate,  localization  accuracy,  lift  requirement, 
and,  of  course,  cost.  Figure  4-1  illustrates  a  head-to-head  comparison  of  these  parameters. 

ipor  System  Two,  the  search  width,  A,  of  588  yards  is  the  assumed  effective  swath  for  the  two  side-scan  sonars 
(one  on  each  of  the  V2  AUVs)  operating  on  adjacent  tracks.  The  search  width  and  operating  altitude  for  V2 
were  intentionally  set  so  that  the  effective  “A”  of  the  following  V2  AUVs  matched  the  “A”  of  the  VI  AUV. 
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System  Definition  Parameters 

SYSTEM  ONE 

SYSTEM  TWO 

Single  Vehicle, 

Multiple 

Multiple  Vehicles,  Distrib- 

Sensor 

uted  Sensors 

Number  of  vehicle  types 

i 

2 

Host-system  comm s  method 

RF  link  via  satellite  or  aircraft 

same 

Reporting  frequency 

Periodic 

same 

System  navigation  fix  method 

GPS  via  periodic  surfacing 

same 

Contact  position  error  threshold  (yards) 

30 

same 

Reliability/redundancy  level 

low  -  in-theater  support  required 

same 

Battery  recharge  method 

not  required 

same 

Delivery  method 

Air 

same 

Recovery  method 

Surface 

same 

Vehicle  Types 

S1V1: 

“LoneAUV” 

S2V1:  ‘ 

Guide” 

S2V2:  “Hunter” 

Number  of  vehicles,  each  type 

1 

1 

2 

Surfacing  requirement? 

Yes 

Yes 

No 

Maximum  length  (feet) 

20 

20 

20 

Maximum  diameter  (inches) 

21 

21 

21 

Maximum  weight  (pounds) 

500 

500 

500 

Sonar  suite 

(1)  ahead-looking  sonar 

(1)  ahead-looking  sonar 

(1)  side-scan  sonar 

(1)  side-scan  sonar 

Identification  sensors 

Video  camera 

None 

Video  camera 

Navigation  suite 

INS  +  D  VS  +  GPS 

INS  +  DVS  +  GPS 

DR  +  DVS  +  acoustic 

tracker 

Communication  suite 

RF  antenna  +  acoustic 

RF  antenna  +  acoustic 

acoustic  modem 

modem 

modem 

Computer /processor 

Basic  guidance  and  con¬ 

Same  as  System  One 

Basic  guidance  and  con¬ 

trol,  kalman  filter,  sonar 

trol 

post-processor 

Battery  type 

Silver-zinc 

Silver-zinc 

Silver-zinc 

Table  4.3:  Case  One  System  Definition  Inputs 
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Tactical  Parameters 

SYSTEM  ONE 
Single  Vehicle, 
Sensors 

Multiple 

SYSTEM  TWO 
Multiple  Vehicles, 
uted  Sensors 

Distrib- 

Search  velocity  (knots) 

6 

6 

Transit  velocity  (knots) 

10 

10 

Navigation  accuracy  (%  DT) 

0.05 

0.05 

Vehicle  Types 

S1V1: 

“LoneAUV” 

S2V1: 

“Guide” 

S2V2: 

“Hunter” 

Vehicle  Altitude  (feet  from  bottom) 

300 

350 

100 

Search  width,  A  (yards) 

ALS:  588  SS:  400 

ALS:  588 

SS:  588 

Probability  of  detection/classification,  B 

ALS:  0.8756  SS:  0.80 

ALS:  0.8756 

SS:  0.90 

Probability  identification 

0.95 

N/A 

0.95 

False  contact  density  (per  sqnm) 

1.0 

N/A 

0.5 

Track  keeping  accuracy  (yards) 

5 

5 

10 

Table  4.4:  Case  One  Tactical  Parameter  Inputs 


Sub-MOE 

System  1 

System  2 

Effective  Area  Coverage  Rate  (sqnm/hr) 

0.48 

0.77 

Percent  Search 

0.977 

0.977 

Localization  Accuracy  (yds) 

15.0 

15.0 

Lift  Requirement  (sqft) 

18.4 

34.7 

Host  Requirement 

0.0 

0.0 

Reporting  Frequency 

0.7 

0.7 

Data  Type 

1.0 

1.0 

Deployment  Phase 

0.3 

0.3 

Mission  Phase 

0.0 

0.0 

Recovery  Phase 

0.0 

0.0 

Costs 

Production  ($) 

225,167 

280,802 

Research  and  Development  ($) 

492,791 

951,554 

Total  System  Cost  ($) 

717,958 

1,232,356 

Table  4.5:  Case  One  Results 
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Overall  MOE  vs  Production  Cost 


O  System  1  ■  System  2 
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Figure  4-2:  OMOE  vs.  Cost  Plot  for  Case  One 

Up  to  this  point,  the  results  obtained  for  each  system  are  given  in  terms  of  the  lower-level 
MOE  with  no  accounting  for  the  weights  previously  established.  For  this  example,  a  decision 
could  possibly  be  made  from  the  non-weighted  results  because  only  a  few  of  them  need  to 
be  compared  and  the  decision-maker  can  apply  their  preference  weighting  mentally.  For  more 
complex  situations,  however,  the  weights  may  need  to  be  formally  incorporated  into  the  results. 
One  way  to  include  the  effect  of  the  weights  is  to  normalize  each  of  the  values  on  a  0  to  1  scale 
(if  not  already  scaled)  and  then  multiply  the  scores  by  the  weights,  as  described  in  Section 
3.6.2.  These  weighted  scores  can  then  be  rolled  up  into  the  overall  MOE  (OMOE)  and  plotted 
against  some  independent  parameter  such  as  cost,  as  done  in  Figure  4-2. 

The  OMOE  versus  cost  approach  is  attractive  in  the  sense  that  it  simplifies  the  analysis 
down  to  just  two  parameters  for  each  system.  The  problem,  though,  is  that  a  decision-maker 
probably  can’t  look  at  just  two  (or  even  a  few)  OMOE  values  and  reach  a  conclusion  as  to 
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which  alternative  is  most  cost-effective.  Unless  the  person  evaluating  the  plot  has  a  very  good 
understanding  of  the  model  being  used,  and  has  observed  the  dynamics  of  the  OMOE  value 
as  system  parameters  are  altered,  they  will  not  be  able  to  decide  what  OMOE  difference  is 
worth  the  associated  cost  difference.  The  OMOE  versus  cost  plot  is  much  more  conducive 
to  comparing  a  larger  number  of  system  alternatives.  Case  Two,  which  examines  five  system 
variants,  provides  a  better  opportunity  to  use  the  OMOE  versus  cost  plot. 

4.2  Case  Two 

4.2.1  Case  Two  Definition 

The  Evaluation  Model  may  be  useful  for  exploring  large  sets  of  system  concepts,  where  the 
number  of  systems  makes  direct  parameter  comparisons  too  difficult.  Case  Two  examines  a 
situation  where  the  evaluator  is  trying  to  determine  the  effect  (on  cost  and  effectiveness)  of 
slightly  varying  the  mix  of  vehicles  in  the  systems.  The  mission,  scenario,  and  MOE  weights 
from  Case  One  apply.  Five  variants  are  formed  by  selecting  from  a  pool  of  three  basic  vehicle 
types,  each  possessing  their  own  baseline  capabilities  but  configurable  for  a  particular  role  in 
a  system.  For  each  variant,  the  number  of  vehicles  and  their  role  (i.e.  sensing  only,  naviga¬ 
tion/communication  only,  or  both)  are  also  varied.  Tables  4.6  and  4.7  summarize  the  system 
definition  and  tactical  parameter  inputs14. 

4.2.2  Case  Two  Results 

The  results  for  Case  Two  are  presented  in  Table  4.8  and  Figures  4-3  and  4-4.  The  formats 
are  identical  to  Case  One,  but  several  additional  parameters  are  plotted  to  capture  all  of  the 
interesting  differences  for  this  case.  With  five  system  variants,  the  direct  comparison  plots 
(Figure  4-3)  reveal  significant  differences  between  the  systems,  but  do  little  to  help  the  evaluator 
decide  which  is  the  most  cost-effective  (especially  if  the  MOE  weights  are  to  be  considered). 
This  is  where  the  OMOE  plot  comes  in.  As  shown  in  Figure  4-4,  the  overall  weighted  MOE 
scores  —  one  for  each  of  the  five  systems  —  are  plotted  against  both  production  and  total  cost, 

14  Systems  3-5  have  two  vehicle  types.  For  each  parameter,  the  input  for  the  first  type  is  listed  on  the  top  row, 
and  the  input  for  the  second  type  is  on  the  second  row. 
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System  Definition  Pa- 

SI 

S2 

S3 

S4 

S5 

rameters 

Number  of  vehicle  types 

1 

1 

2 

2 

2 

Host-system  com  ms  method 

RF -Satellite 

RF-Satellite 

RF-Satellite 

RF-Satellite 

RF-Satellite 

Reporting  frequency 

Periodic 

Periodic 

Continuous 

Continuous 

Continuous 

System  navigation  fix  method 

GPS  -  surface 

GPS  -  surface 

GPS  -  link 

GPS  -  link 

GPS  -  link 

Contact  position  error  thresh- 

30 

30 

10 

10 

10 

old  (yards) 

Reliability/redundancy  level 

High 

High 

High 

High 

High 

Battery  recharge  method 

Not  required 

Not  required 

Not  required 

Not  required 

Not  required 

Delivery  method 

Air 

Air 

Air 

Air 

Air 

Recovery  method 

Surface 

Surface 

Surface 

Surface 

Surface 

Vehicle  Types 

Hunter 

Mini-hunter 

Guide 

Guide 

Guide 

Mini-hunter 

Mini-hunter 

Hunter 

Number  of  vehicles,  each  type 

2 

4 

1 

1 

2 

2 

3 

4 

Surfacing  requirement? 

1 

1 

0 

0 

0 

Sonar  suite 

ALS-21,  SS-12 

ALS-12,  SS-12 

None 

None 

None 

ALS-12,  SS-12 

ALS-12,  SS-12 

ALS-21,  SS-12 

Identification  sensors 

ID-MED 

ID-MED 

None 

None 

None 

ID-MED 

ID-MED 

ID-MED 

Navigation  suite 

INS+DVS+GPS 

INS+DVS  +  GPS 

DR+DVS+GPS 

DR+DVS+GPS 

DR+DVS+GPS 

D  R+D  VS  +  tracker 

DR+D  VS  +  tracker 

DR+DVS  + tracker 

Communication  suite 

RF 

RF 

RF 

RF 

RF 

Acoustic  modem 

Acoustic  modem 

Acoustic  modem 

Compu  ter /processor 

GC+K+S 

GC+K+S 

GC  +  S 

GC+S 

GC  +  S 

GC 

GC 

GC 

Battery  type 

Li-Poly 

Li-Poly 

Li-Poly 

Li-Poly 

Li-Poly 

Table  4.6:  Case  Two  System  Definition  Inputs 


Tactical  Parameters 

SI 

S2 

S3 

S4 

S5 

Search  velocity  (knots) 

4 

4 

4 

4 

4 

Transit  velocity  (knots) 

6 

6 

6 

6 

6 

Vehicle  Altitude  (feet  from  bottom) 

50 

50 

300 

300 

300 

50 

50 

50 

Search  width,  A  (yards)  [ALS  /  SS] 

400  /  160 

200  /  160 

N/A 

N/A 

N/A 

200  /  160 

200  /  160 

400  /  160 

Probability  of  detection/classification,  B  [ALS  /  SSj 

0.5  /  0.85 

0.4  /  0.85 

N/A 

N/A 

N/A 

0.4  /  0.85 

0.4  /  0.85 

0.5  /  0.85 

Probability  identification 

0.9 

0.8 

0.8 

0.8 

0.9 

False  contact  density  (per  sqnm) 

1.0 

1.5 

1.5 

1.5 

1.0 

Navigation  accuracy  (%  DT) 

0.05 

0.05 

0.05 

0.05 

0.05 

Track  keeping  accuracy  (yards) 

10 

10 

20 

20 

20 

Table  4.7:  Case  Two  Tactical  Parameter  Inputs 
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Sub-MOE 

SI 

S2 

S3 

S4 

S5 

Eff.  Area  Coverage  Rate  (sqnm/hr) 

0.32 

0.35 

0.26 

0.39 

0.98 

Percent  Search 

0.939 

0.901 

0.901 

0.901 

0.933 

Localization  Accuracy  (yds) 

15.00 

15.00 

5.00 

5.00 

5.00 

Lift  Requirement  (sqft) 

42.88 

38.38 

23.71 

31.61 

27.00 

Host  Requirement 

1.00 

1.00 

1.00 

1.00 

1.00 

Reporting  Frequency 

0.70 

0.70 

1.00 

1.00 

1.00 

Data  Type 

1.00 

1.00 

1.00 

1.00 

1.00 

Deployment  Phase 

0.30 

0.30 

0.30 

0.30 

0.30 

Mission  Phase 

0.00 

0.00 

0.00 

0.00 

0.00 

Recovery  Phase 

Costs 

1.00 

1.00 

1.00 

1.00 

1.00 

Production  ($) 

452,121 

290,348 

234,043 

240,595 

882,654 

Research  and  Development  ($) 

492,792 

739,018 

1,371,346 

1,261,144 

629,390 

Total  System  Cost  ($) 

944,913 

1,029,366 

1,605,389 

1,501,739 

1,512,044 

Table  4.8:  Case  Two  Results 


providing  a  compact  indication  of  the  relative  cost-effectiveness  of  each  system. 

Unfortunately,  the  OMOE  method  is  not  so  ideal  as  to  provide  a  definitive  answer  regarding 
which  system  is  “the  best” .  The  decision-maker  must  determine  the  level  of  effectiveness  that 
they  are  willing  to  pay  for.  The  decision  is  further  complicated  by  the  presence  of  two  different 
costs,  one  or  the  other  of  which  may  be  more  important  for  some  reason.  These  cost-related 
preferences  are  not  captured  in  the  OMOE  vs.  Cost  plots,  nor  are  a  number  of  other  factors 
that  could  influence  the  decision.  Still,  the  OMOE  approach  greatly  simplifies  the  problem  for 
the  decision-maker,  enabling  them  to  apply  judgement  and  reasoning  in  consideration  of  any 
remaining  factors  in  order  to  reach  a  decision  or  conclusion. 
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Chapter  5 


Conclusion 


5.1  Summary  of  Work 

The  main  objective  of  this  thesis  was  to  develop  an  analytical  framework  for  the  evaluation 
of  advanced  search  concepts  for  multiple- AUV  MCM.  Supporting  objectives  called  for  identi¬ 
fying  suitable  metrics  for  evaluating  multi- AUV  MCM  systems,  defining  and  constructing  the 
evaluation  framework,  and  demonstrating  its  functionality  and  usefulness.  The  pursuit  and 
attainment  of  these  objectives  led  to  the  following  “deliverables”: 

•  A  recommended  approach  and  associated  methodology  for  evaluating  unmanned/ autonomous 
MCM  systems,  including  multiple- AUV  MCM  systems. 

•  An  effectiveness  model,  for  measuring  the  degree  to  which  a  set  of  mission  objectives  is 
satisfied  according  to  the  preference  structure  of  the  warfighter. 

•  A  system  model,  for  transforming  user-specified  system  requirements  into  a  feasible  design 
that  is  described  by  numeric  values  representing  physical  characteristics  and  performance. 

The  evaluation  approach  uses  MOP  and  MOE,  and  the  relationships  between  them,  to  de¬ 
scribe  a  series  of  systems  in  terms  of  physical/performance  characteristics  and  then  to  translate 
those  characteristics  into  numeric  values  reflecting  the  mission-effectiveness  of  the  systems.  The 
mission-derived  MOE  are  organized  into  a  hierarchy  and  weighted,  using  AHP  techniques,  ac¬ 
cording  to  the  warfighter’s  preferences  for  a  given  scenario.  Utility  functions,  modeling,  and 
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simulation  provide  alternative  means  of  relating  these  MOE  to  the  system  MOP.  Implemen¬ 
tation  of  this  approach  involves  two  computer-based  models:  the  Effectiveness  Model  and  the 
System  Model. 

The  Effectiveness  Model  contains  five  MOE  and  eleven  subordinate  MOE  which  are  intended 
to  collectively  portray  the  overall  mission-effectiveness  of  any  MCM  system,  but  are  especially 
geared  toward  unmanned/autonomous  systems.  Additionally,  the  model  is  meant  to  facilitate 
evaluation  and  comparison  of  MCM  systems  for  all  types  of  operations,  including  minehunting 
and  mine  clearance.  Despite  the  intentions,  the  MOE  selected  may  not  be  perfectly  suitable 
for  representing  the  present  or  future  mission.  A  formal  decomposition  of  the  mission  need  by 
a  panel  of  experts  (using  a  QFD  or  similar  technique)  might  reveal  a  different  set  of  MOE.  The 
Effectiveness  Model  can  easily  accommodate  such  replacemen  is  and  modifications. 

The  System  Model  provides  the  environment  in  which  candidate  AUV  MCM  systems  are 
defined  and  characterized.  Whereas  the  Effectiveness  Model  applies  generally,  the  System  Model 
handles  a  limited  range  of  AUV  concepts.  The  acceptable  range  of  configurations  is  fairly  broad, 
including  single-  and  multiple- AUV  concepts  with  various  mixes  of  sensors,  navigation  packages, 
communications  gear,  batteries,  etc.  The  more  significant  limits  have  to  do  with  operational 
tactics  and  system  behavior ,  and  are  summarized  as  follows.  MCM  operations  are  confined 
to  minehunting  —  detection  through  identification,  but  not  clearance.  A  system  is  assumed  to 
operate  as  a  cohesive  unit,  except  that  individual  vehicles  may  conduct  minor  excursions  for 
mine  prosecution  and/or  navigation  and  communication.  The  time  required  for  these  excursions 
is  added  to  the  mission  time.  The  search  pattern  is  restricted  to  progressive  runs  along  parallel, 
uniformly-spaced  tracks  (lawnmower  pattern)  in  a  rectangular  search  area. 


5.2  Applications  and  Future  Work 

The  models  developed  for  this  thesis  are  not,  themselves,  meant  to  be  used  for  comprehensive 
evaluation  of  multi- AUV  MCM  system  concepts.  Instead,  it  is  the  framework  -  the  approach 
and  its  associated  methodology  —  that  was  developed  with  this  intention  in  mind.  The  Effec¬ 
tiveness  Model  and  System  Model  developed  here  serve  mainly  to  demonstrate  the  approach. 
Two  core  applications  for  the  evaluation  framework  were  stated  in  Section  1.3.  The  first 
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application  relates  to  AUV  MCM  system  design  and  procurement  decisions.  The  second  ap¬ 
plication  has  to  do  with  operational  employment  of  a  given  system,  assuming  it  already  exists. 
For  both  applications,  the  evaluation  framework  helps  to  guide  exploration  of  the  vast  trade- 
space  associated  with  AUV  MCM  system  concepts,  with  the  ultimate  goal  being  to  identify  the 
most  effective  design,  configuration,  or  employment  alternative  as  weighed  against  some  cost(s), 
monetary  or  otherwise.  In  the  design/procurement  case,  the  framework  provides  a  means  of 
designing  to  mission- effectiveness,  rather  than  optimizing  the  design  to  a  set  of  performance 
specifications.  This  is  a  very  powerful  approach  because  it  enlightens  the  designers,  allowing 
them  to  observe  and  understand  the  impact  of  engineering  decisions  on  the  ultimate  usefulness 
of  the  end  product.  By  gaining  this  insight  early  in  the  design  process,  costly  re-work,  due  to 
uninformed  decisions  and/or  changes  in  the  mission  requirements,  can  be  minimized.  Regarding 
the  employment  application,  the  framework  offers  an  opportunity  to  explore  a  much  larger  field 
of  operational  paradigms  than  would  be  examined  during  the  design  process.  This  may  include 
assessing  different  system  configurations  (formed  by  mixing  and  matching  re-configurable  ve¬ 
hicles  and  sub-systems)  and  altering  tactical  parameters  (e.g.  speed,  search  pattern,  contact 
prosecution  algorithms)  under  a  variety  of  scenarios. 

A  significant  milestone  for  the  evaluation  of  multi- AUV  systems,  for  any  mission,  will  be 
the  development  of  a  high-resolution,  high-fidelity  modeling /simulation  environment  in  which 
a  broad  range  of  system  concepts  can  be  consistently  and  accurately  evaluated  in  terms  of 
mission-effectiveness  and  cost.  The  Effectiveness  Model  and  System  Model  represent  a  step  in 
this  direction,  but  much  work  remains.  In  particular,  the  limitations  of  the  System  Model  should 
be  addressed.  While  a  “static”  analytical  model  appears  to  be  sufficient  for  describing  most  of 
the  physical  characteristics  of  a  multi- AUV  system,  and  perhaps  the  basic  aspects  of  individual 
vehicle  performance,  simulation  may  be  preferable  for  addressing  the  more  complex  and  time- 
dependent  issues  associated  with  tactical  and  operation  employment.  For  example,  a  simulator 
could  replicate  exotic  search  algorithms  that  enable  the  multi- AUV  system  to  change  tactics  in¬ 
stride,  say,  in  response  to  changes  in  bottom  clutter  density.  Simulation  capability  may  also  be 
used  to  augment  a  static  model.  In  the  case  of  the  System  Model,  the  sensing  and/ or  navigation 
performance  of  multi- AUV  systems  could  be  provided  by  a  simulator  designed  for  that  specific 
purpose,  thus  relieving  the  user  of  this  burden  and  allowing  more  unusual  system  concepts 
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to  be  explored.  High-fidelity  performance  simulators  for  critical  areas  (sensing,  navigation, 
communication,  etc.)  will  be  essential  to  the  implementation  of  a  comprehensive  multi-AUV 
MCM  system  evaluation  framework. 

While  improvements  in  the  framework’s  technical  capabilities  are  important,  more  criti¬ 
cal  areas  for  future  work  relate  to  the  types  of  analyses  that  can  be  performed  and  the  na¬ 
ture/presentation  of  the  information  provided  by  the  framework.  For  example,  the  Evaluation 
Model  supports  high-level,  effectiveness-based  comparison  of  any  number  of  system  concepts, 
but  lacks  the  internal  relationships  and  consistency  checks  necessary  for  detailed  sensitivity 
analyses.  Incorporating  the  capability  to  adjust  individual  system  parameters  and  immediately 
observe  the  impact  on  mission-effectiveness  over  a  range  of  inputs  would  significantly  enhance 
the  power  of  the  evaluation  framework. 

5.3  Closing 

This  thesis  represents  more  than  the  individual  effort  of  the  author.  Many  people  graciously 
contributed  to  this  work,  providing  technical  information,  expert  advice,  general  guidance, 
and  just  plain  old  support.  Perhaps  the  most  rewarding  part  of  this  experience  has  been  the 
fascinating  dialog  that  resulted  from  interacting  with  members  of,  and  contributors  to,  the 
Navy’s  mine  warfare  community.  It  is  the  author’s  hope  that  both  the  process  and  the  final 
product  serve  to  benefit  the  community  and  the  persons  associated  with  it. 
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Appendix  A 


AUV  MCM  System  Evaluation 
Model  Technical  Information 


The  Evaluation  Model  template  resides  in  three  distinct  Mathcad  files.  One  file  is  dedicated  to 
the  Effectiveness  Model  (Appendix  C);  the  other  two  files  contain  the  System  Model  (Appendix 
B).  The  AUV  Design  Module  is  separate  from  the  Input  and  Mission  Planning  Modules  so  that 
multiple  AUV  types  can  each  be  modeled  in  a  unique  file.  Imbedded  in  the  System  Model  is 
an  Excel  file  that  contains  a  user  interface  sheet  (part  of  the  Input  Module)  and  a  series  of 
databases  for  AUV  sub-component  characteristics  (see  Appendix  D). 

The  Mathcad  files  are  connected  through  “reference  links”,  allowing  information  to  flow 
from  the  Input  and  Mission  Planning  Modules  to  both  the  AUV  Design  Module  and  the  Ef¬ 
fectiveness,  as  illustrated  in  Figure  A-l.  Each  reference  link  must  be  manually  updated  if  the 
reference  filename  changes.  Similarly,  the  three  output  (file  write)  components  at  the  end  of 
the  Effectiveness  Model  should  also  be  updated  so  that  the  new  output  files  are  created  with 
the  desired  filenames.  It.  is  recommended  that  the  output  components  be  disabled  before  the 
new  Effectiveness  Model  file  is  created  in  order  to  avoid  overwriting  other  output  files. 
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Figure  A-l:  Evaluation  Model  File  Structure 
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Appendix  B 


System  Model 


SYSTEM  MODEL 


Model  Description 

The  System  Model  is  the  starting  point  for  an  evaluation  problem.  It  has  two  main  purposes: 

(1)  To  provide  an  environment  in  which  to  design/configure  a  notional  AUV  system 

(2)  To  determine  the  system  MOP  required  as  input  to  the  Effectiveness  Model 

Three  modules  make  up  the  System  Model: 

-  INPUT  MODULE:  Scenario  and  tactical  parameters  are  entered  in  the  Mathcad  worksheet;  system-level 
and  vehicle/paylod  entries  are  made  in  an  Excel  worksheet  through  a  link.  The  Excel  sheet  contains 
databases  with  AUV  sub-system  weigth,  volume,  and  power  data. 

-  MISSION  PLANNING  MODULE:  Calculates  total  mission  time  required  to  achieve  Percent  Search 
objective,  as  well  as  the  actual  (achieved)  Percent  Search  (almost  always  greater  than  the  objective). 

-  AUV  DESIGN  MODULE:  This  module  resides  in  a  separate  file  in  order  to  accommodate  the  design  of 
multiple  AUV  types. 


Constants 


dB  :=  101og(  weber- m  2  10  12- weber  ^m2) 


nm  :=  2025yd 


knt 


nm 

1-hr 
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I.  MISSION  AND  SYSTEM  INPUTS 


A.  Scenario  Parameters 

1.  Mission  Objectives 

Minehunting  Objective:  Mission  Type  Typical  Objective  Psearch_desired:“ 

Exploratory  first-look  xx 

Given  as  "Percent  Search"  achieved  through  Basic  reconnaissance  xx 

minehunting  for  detection,  classification,  and  Detailed  mapping  xx 

up  through  identification.  Enter  fractional 
values  as  illustrated  in  guide  table  at  right. 


Search  area  dimensions: 


Specify  delivery/recovery  methods  (e.g. 
air,  sub,  surf)  through  Excel  link  below. 


Distance  from  point  of  entry  to  search  area: 
Distance  from  search  area  to  recovery  point: 


^earcharea:~  3nm 

Wsearcharea:==400fyd 


^ingress 


2.  Environment 
Bottom  Type: 


Bottom  Type  Number  Desiq 

Gravel  4 

Sand  9 


BT  :=  4 


Average  Water  Depth: 


uavg 


:40Gft 


3.  Mine  Threat 

Estimated  number  of  mines  in  search  area:  NM  :=  25 

Fraction  Of  undetectable  mines:  Zero  entry  is  best  for  comparisons,  and  is  appropriate  p  ;=|0 

if  the  individual  sonar  detection  probabilities  {B 
values)  account  for  undetectable  mines.  Entering  a 
value  here  implies  that  a  certain  fraction  of  mines  are 
undetectable  by  ALL  of  the  sensors  in  the  system. 

Mine  target  Strength:  This  parameter  is  used  only  as  a  reference  for  Sonar  y  ;=  ~30dB 

Performance  Parameter  entries  (Section  I.C.3). 


B.  System  Definition 

1.  Excel  Input  Link 

Double  click  on  the  icon  Enter  inputs  in  yellow-shaded  areas 
of  interface  worksheet  inside  Excel.  Use  database  sheets  to 
guide  input  When  finished,  save  and  close  the  link.  Click  once 
on  the  icon  and  press  F9  to  update  Mathcad  with  the  new  info. 


(  sysreqs  ^ 
vehreqs 
\  payload  j 


Worksheet 
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System-Level  Requirements 


Comments/Legend 


Number  of  vehicle  types 


Host-system  com  ms  method 


Reporting  frequency 
System  navigation  fix  method 


Contact  position  error  threshold  (yds) 
Reliability/redundancy 


Battery  Recharge  method 
Delivery  method  for  clandestine  ops 


Recovery  method  for  clandestine  ops 


2  Selection  must  agree  with  number  of  entries  in  "Vehicle  Requirements  section 
RF-SAT  AM=acoustic  modem,  RF-LOS=radio  freq  via  line  of  sight,  RF-SAT=radio  freq  via  satellite  or  aircraft, NR=not  required 

PRD  CONT=continuous,  PRD=periodic,  NR=not  required  Note:  enter  achievable  reporting  frequency  based  on  comms  method 
and  opportunity  to  report  (e  g.  surface  to  transmit  RF,  host  within  AM  range,  etc.) 

GPS-SURF  GPS-SURF=GPS  by  surfacing,  GPS-LINK=constant  GPS  (e  g.  buoys  or  antenna),  LBL=Long  Baseline  or  other  array, 
NOFIX=DR  only  Note:  enter  method  for  system,  regardless  of  which  vehicles  are  involved  in  actual  position  fixing 
30  Maximum  acceptable  distance  between  actual  and  reported  contact  positions. Note:  set  value  to  reflect  the  achievable 
threshold  using  fix  method  prescribed  above 

LOW  LOW=system  requires  an  in-theater  support  platform  during  search  phase;HIGH=system  does  not  require  a  support  platform 
in  theater  during  search  phase  or  is  expendable. 

NR  HOST=vehicles  rely  on  host  platform  for  battery  recharge ;DOCK=battery  recharge  via  in-water  docking  stations  or 
equivalent  system;  NR=not  required  (i.e.  endurance  is  greater  than  mission  time) 

AIR  SUB=submarine,  AIR=aircraft,  SURF=surface  ship  Note:  same  for  all  vehicles  in  system 

SURF  SUB=submarine,  A!R=aircraft.  SURF=surface  ship  Note:  same  for  all  vehicles  in  system 


I  Vehicle  Requirements  and  Payload 

Item  Units 


Type/Role 
Number  of  vehicles  (this  type) 
Surfacing  requirement  toggle 
Max  Length 
Max  Diameter 
Max  Deadweight 
Sonar #1 
Sonar  #2 
Sonar  #3 
ID  Sensor 
Nav  Suite 
Comms 

Computer/Processor 
Battery  Type 
Sensor  Suite  Weight 
Sensor  Suite  Volume 
Sensor  Suite  Power 
Nav  Suite  Weight 
Nav  Suite  Volume 
Nav  Suite  Power 
Comms  Suite  Weight 
Comms  Suite  Volume 
Comms  Suite  Power 
Computer/Processor  Weight 
Computer/Processor  Volume 
Computer/Processor  Power 
Battery  Specific  Energy 
Battery  Energy  Density 
Battery  Weight  to  Volume  Ratio 


guide 

1 

1 

20 

21 

500 

ALS-21 

0 

0 

0 

INS-DVS-GPS 

AM+RF 

GC+K+S 

Ag-Zn 


W' ' 

:  T  ™ 

ouin  146.5 

watt  23.0 

|  own  ,61.7  \ 

£ ' :  i.i£ :  ■*&>’&* 

. 

watt-hr/orft  5097  0 
ib/cuft  124,9 

User  must  ensure  that  payload 


Vehicle  Number 
2  3 


hunter  0  0 

2  0  0 

0  0  0 

20  0  0 

21  0  0 

500  0  0 

SS-12  0  0 

0  0  0 

0  0  0 

ID-LOW  0  0 

DR-DVS-ABR  0  0 

AM  0  0 

GC  0  0 

Ag-Zn  0  0 

.Aw  ~~  >  «  o,o  -  -  \ 

41-0  0.0  0.0 

20.6  0.0  0.0 

719.8  0.0  O.Q 

■  >...  «*  <*  *  An 


37.0  0.0 


Bl;  9.0 


Comments/Legend 


Choose  differentiating  name 
1  if  yes,  0  if  no 

Ensure  consistency  with  system  reqs;  zero  if  no  limit 
Ensure  consistency  with  system  reqs;  zero  if  no  limit 
Ensure  consistency  with  system  reqs;  zero  if  no  limit 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
Use  exact  desig  from  database 
I  NOTE:  check  these  lookup  formulas  if  databases  changed 

assume  100%  duty  cycle 


assume  100%  duty  cycle 


components'  diameters  correspond  with  max 


assume  100%  duty  cycle 


1  assume  100%  duty  cycle 


Not  used 
vehicle  diameter 
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2.  System  Requirements 


Variable  assignment: 

submatrix(A,  ir,jr,ic,jc)  returns  the  matrix  consisting  of  rows  ir  through  jr 
and  columns  ic  through  ic  of  array  A. 
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type  :=if(mimtype  as  1,  vehreqs  l  numtype+2,submatrix(vehreqs  ,  1, 1,3,  numtype  +  2)) 
numveh  :=if(  numtype  =  l,vehreqs 2inumtype+2»submatrix(vehrecls  ,2, 2, 3, numtype  +  2)) 
surf_req  :=  if(numtype  =  1 , vehreqs 3 ? niimtype+2 , submatrix( vehreqs  ,3, 3, 3, numtype  +  2)) 
Lmax:=  numtype  a  1, vehreqs  4  numtype+2,submatrix( vehreqs  ,4, 4, 3, numtype  +  2))-ft 
Dmax:=  if( numtype  =  1 , vehreqs  5 ? numtype+2 , submatrix( vehreqs  ,5, 5, 3, numtype  +  2)) -in 
Wmax :=  if( numtype  =  1, vehreqs  6  numtype+2,submatrix( vehreqs  ,6,6, 3, numtype  +  2))lb 


type  =  ( "guide"  "hunter"  ) 
numveh  =  ( 1  2) 
surf_req  -  ( 1  0) 

Lmax=  (20  20)  ft 
Dmax=(21  21)  in 
Wmax  =  (500  500)  lb 


4.  Vehicle  Payload 

From  spreadsheet  link: 


1 

2 

3 

4 

1 

"Sonar #1" 

"ALS-21" 

"SS-12" 

2 

"Sonar  #2" 

0 

0 

3 

"Sonar  #3" 

H  M 

0 

0 

4 

"ID  Sensor" 

It  ft 

0 

"ID-LOW" 

5 

"Nav  Suite" 

5-DVS-GPS" 

*-DVS-ABR" 

6 

"Comms" 

w_j rt 

"AM+RF" 

"AM" 

7 

r/Processor" 

H  II 

"GC+K+S" 

"GC" 

8 

attery  Type" 

"Ag-Zn" 

"Ag-Zn" 

9 

uite  Weight" 

"lb" 

20.3 

7.175 

10 

jite  Volume" 

"cuin" 

924 

718.38 

11 

Suite  Power" 

"watt" 

139.4 

41 

12 

uite  Weight" 

"lb" 

9.969 

20.55 

13 

jite  Volume" 

"cuin" 

146.51 

719.753 

14 

Suite  Power" 

"watt" 

22.95 

24.25 

15 

uite  Weight" 

"lb" 

2.5 

1.5 

16 

jite  Volume" 

"cuin" 

61.714 

37.029 

17 

Suite  Power" 

"watt" 

12 

9 

18 

jsor  Weight" 

"lb" 

4 

2 

19 

sor  Volume" 

"cuin" 

300 

75 

20 

ssor  Power" 

"watt" 

40 

15 

21 

oific  Energy" 

"watt-hr/lb" 

40.824 

40.824 

22 

rgy  Density" 

watt-hr/cuft" 

5.097-103 

5.097-103 
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Variable  assignment: 


Wsensors :=  iftnumtype  =  1, payload 9>nuintype+2>submatri)<payloa(i ,9,9,3, numtype  +  2))-lb  Wsensors  =  (20.3  7.175)  lb 

vsensors :==  iflfnumtype  =  1, payload  10>numtype+2,submatri)<payload ,  10, 10, 3, numtype  +  2))- in3  Vsensors  =  (924  718.4)  in3 

Censors  :=  if(numtype  =  1  .payload ! lt numtype+2,submatri?<payload ,  1 1, 1 1,3, numtype  +  2))- watt  Psensors  =  (139-4  41)  watt 

Wnav  :=  if(numtype  =  1,  pay  load  l2Tuimtype+2,submatrix(pay  load,  12, 12, 3,  numtype  +  2))db  =  (9.969  20.55)  lb 

Vnav :=  if(numtype  as  1 ,  payload  j  3 1  numtype+2 » submatrix(payload  ,13,13,3,  numtype  +  2))  *  in3  Vnav  —  ( 146.5  7 1 9 .8)  in3 

Pnav  :=  if(numtype  =  1 , payload  ,4>  numtype+2, submatri)< payload ,  14, 14, 3, numtype  +  2))-  watt  Pnav  =  (22.95  24.25)  watt 

Wcomms  if(numtype  =  1 ,  payload  15>  numtype+2,  submatrix(payload  ,15,15, 3,  numtype  +  2))  lb  Wcomms  =  ( 2.5  1 .5)  lb 

Vcomms:=if(numtyPe=  1  .payload  16  numtype+2 , submatrix( payload ,  1 6, 1 6, 3, numtype  +  2))in3  Vcomms  =  (61.7  37)in3 

Pcomms if(numtype  s  1, payload  17  numtype+2,submatri>(payload,  17, 17,3,numtype  +  2))- watt  Pcomms  -  (12  9)  watt 

W  computer :=  if(  numtype  =  1 ,  payload  ,  8 ;  numtype+2 ,  submatri><payload ,  1 8, 1 8, 3 ,  numtype  +  2))lb  Wcomputer=(4  2)  lb 

^computer :=  if(numtype  =  1, payload  19<  numtype+2,subrnatri)<payload  ,19, 19, 3, numtype  +  2)) -in3  Vcomputer -  (300  75)  in3 

Pcomputer:=  ^numtype  =  1 , payload 20  numtype+2 » submatrix(payload ,  20, 20, 3 , numtype  +  2))- watt  PcomputCr  =  (40  15)  watt 

Vbatteiy:=if(numtype  ■  1 , payload 2 j  t  numtype+2 ,  submatri><payload  ,21,21,3, numtype  +  2))-—^  Ybattery  =  (40.824  40.824)  ^  h 

,  v  watt -hr  watt- hr 

P battery :=  if(numtype  =  l,payload22  numtyPe+2>submatri5<payload,22,22,3,numtype  +  2)) - —  p battery  =  ( 5097  5097) - - 

ft3  ft 


C.  Tactical  Parameters 

1.  Speed  and  Endurance 

Search  Speed: 
Transit  Speed: 
Prosecution  speed: 

2.  Search  Parameters 
Vehicle  Altitudes: 


Note:  This  version  of  the  model  assumes  the  following: 

(1)  all  vehicles  In  the  system  move  together  at  the  same  speed 

(2)  all  vehicles  must  have  enough  endurance  to  complete  mission 

Vscarch:=  6knt  Average  system  search  speed;  individual 

vehicles  may  travel  at  different  speeds. 

^transit :==  lOkm  Vehicles  assumed  to  transit  en  masse 

Vprosecme  :=  V^i,  Speed  at  which  ID-tasked  vehicle(s) 

prosecute  mine-like  contacts;  this  can  be 
adjusted  to  "even  out"  vehicle  mission 
times  (computed  at  the  very  end  of  this 
model).  Should  not  go  above  \fansit. 


ALT (350  100  0  0)ft 


ALT  must  not  exceed 
avg  depth. 
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3.  Sonar  Performance  Parameters 


1 .  Enter  sonar  performance  parameters  FOR  EACH  SONAR  in  terms  of  the  characteristic  search  width  "A"  and  characteristic 
probability  of  detection/classification  "B".  [These  simplified  values  can  be  derived  from  a  "probability  of  detection  as  a 
function  of  lateral  distance",  or  P(y)  curve;  Reference  PEO(MIW)  INST  3370  for  definition  of  these  parameters.] 

2.  The  following  reference  parameters  are  provided  for  looking  pre-determined  up  the  "A"  and  "B"  values  (reference  MCM 
Future  Systems  Study  for  some  notional  ALS,  SAS,  and  SS  sonar  values): 

vehicle  altitude  (ALT)  search  speed  (Vs) 

bottom  type  (BT)  target  strength  ( 7) 

water  depth  (d  avg) 

3.  For  cooperative  multi-AUV  operations,  the  A  and  B  values  can  be  adjusted  to  reflect  the  "effective"  performance  due  to 
more  efficient  search  tactics  and/or  increases  in  search  probabilities  due  to  communication  between  vehicles,  data  fushion, 
multi-static  operations,  and  so  forth. 

Reference  Parameters:  Sonar_Suite  :=  submatrix(payload ,  1 , 3, 1 , 6) 


!" .  . /'"Sonar #1"  "ALS-21H  "SS-J2”  0  0N 


Sonar  Suite  =  "Sonar  #2”  0 


l  "Sonar  #3” 


«  :  0 


0  0  0 
0 . 0  v 


:Vs£arch=6knt  ALT  =  (350  100  0  0) ft 


=  400ft  y  =  -30dB 


Sonar  Parameter  Entry: 


Vehicle  types 


Characteristic  Search  Width 


^588  588  0  0  |  Sonar 
A  :=  0  0  0  0  yd  types 

i  0  0  00j 


Characteristic  Probability  of  Detection/Classification  b  :=  0 


0.8756  0.95  0  0 


0  0  0 
0  0  0 


Probability  of  identifying  a  mine  as  a  mine 


P  •=  95 

rimm  * 


False  contact  density  for  identification 


^inm  ■= 


Must  be  less  than  total 
mine  density 


I  NM  ,  •  •  -2 

. . . . . . =  4.219nm  , 

|  4earchareaWsearcharea 


4.  Navigation  Performance  Parameters 


Navigation  "growth  error”  (for  system):  <>/0DT  ;=  o.05 

Standard  deviation  of  track  keeping:  a:=(5  10  0  0)yd 


<*1,1  <*1,2  <*1,3  <*1,4 

a  :=  <*1,3  al,4 

^<*1,1  <*1,2  <*1,3  <*1,4, 
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II.  MCM  MISSION  PLANNING  MODULE  Based  on  Uniform  Clearance  (UCPLN) 

- “  Theory  (ref.  PEO(MIW)  INST  3370) 

A.  Probability  Parameters 

1.  Non-dimensionalization 

Act  W  search  area  ^  ^  ^track 

And:=“T  and ~7  Dtrack  •=  ~  Dtrack.nd :=  , 

yd  yd  N  ya 


Note:  N  =  number  of  tracks,  a 
global  variable  defined  at 
Section  il.C. 


2.  MCM  Efficiency  Coefficient 

Y  is  the  coefficient  of  MCM  efficiency.  In  simple  terms  it  is  the  payoff  from  covering  the  area  in  an  orderly  manner,  rather  than 
randomly.  As  randomness  decreases  (B  increasing  or  <* decreasing)  Y  increases.  This  equation  was  derived  by  Dr.  R.K.  Reber 
many  years  ago  by  averaging  the  probability  of  clearance  between  two  parallel  tracks  in  the  central  part  of  the  channel  where 
there  were  no  edge  effects;  i.e.,  the  channel  edges  were  far  enough  away  to  the  left  and  right  that  extending  the  width  of  the 
channel  would  have  no  effect. 


Y  := 


for  i  €  1 ..  rows(A) 
for  j  e  1..  cols  (A) 


2*  <Tnd. 


yu<- 


And.  .‘®i, j 


roc 

- 

( 

r  And .  > 

/ 

And  > 

y 

In 

1  -  Bj  r 

cnorm 

u  + - — 

-  cnorm 

u  - 

- ii. 

2'CTnd 

2-Cnd 

_ 

V 

V  '•<> 

V 

ui) 

J . 

du  if  Bj  j  *  0 


Y  =  (2.357  3.066) 


3.  "M"  Term 

M  represents  a  combination  of  the  level  of  coverage  {the  search  width,  A,  times  the  number  of 
runs,  J,  divided  by  the  drack  spacing,  D)  and  the  success  of  detection/classification  over  the  area 
covered  (probability,  B). 


M  := 


lor  i  e  l.. 
for  j  e  1..  cols  (A) 
J‘And 

^track.nd 


if  B, 


m 


M  =  (0.901  0.978) 
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C.  Required  Search  Parameter  Values  (to  achieve  desired  Percent  Search) 

Adjust  to  get  desired  P  seardT 

Required  number  of  tracks: 

Number  of  runs  per  track: 

Track  Spacing:  Ensure  Dtrack  is  less  than 

the  smallest  non-zero  A  value 


D.  Mission  Time 

1.  Transit  Time 

Transit  distance: 

^transit 

”  ^ingress  +  ^egress 

^transit 

=  6nm 

Transit  time: 

^transit 

^transit 

^transit 

T 

1  transit 

=  0.6hr 
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2.  Search  Time 


Total  track  distance: 


dtrack  runs •—  Lsearcharca^’ J 


d  track  runs  —  2 1  nm 


Total  turns  distance: 


dtums  :=  t(N'J)  -  l]*Dtrack*  1.1  assumes  10%  "excess- 

on  each  turn 


Search  distance  (incl  turns):  dscarch:=  d***  +  dh 


drums  =  1.862nm 


dsearch  —  22.9nm 


Search  time: 


T  search  •“  " 


Tsearch~  3.8 lhr 


3.  Comm/Nav  Excursion  Time 


System  common  parameters: 


Nav/comm  reqs  (from  input):  fixjmethod  =  "GPS-SURF” 

report_freq  =  "PRDM 


"No  fix"  interval:  applicable  to  systems  dno  flx:= 

with  fixing  capability 


max_pos_error 


d„0  fix  =  600yd 


Frequency/number  of  fixes: 


Nfixes =  70.875 


Vehicle  parameters  (arrays  indicate  values  for  specific  vehicle  types): 


Vehicle  surfacing  rqmts  (from  input):  surf  req  =  ( 1  0) 


1  =  surf  req,  0  =  no  surf  req 


Number  of  surfacing  evolutions: 


Nsurf:~.Nfix 


assumes  number  of  fixes  dictated 
by  nav  requirements 


Time  on  surface  (typical  value): 


Txmit  recv :=  Osec 


(enter  zero  if  negligible) 


Ascent/descent  rate  (typical  value):  ascent  descent_rate  ^  200- 


Distance  to  surface:  *  alt  ;=  if(numtype  =  1 ,  ALT i  j ,  submatrix( ALT,  1,1,1, numtype )) 

alt  =  (350  100)  ft 


dsurface*"-  davg  alt 


dSurface=(50  300)  ft 


Ascent/descent  time: 


1  ascent  descent  •— 


2dSUrface 

ascent  descent  rate 


Tascent  descent—  (0*5  3  )  min 
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Excursion  time  summary:  xe 
(for  each  vehicle) 


for  i  e  1..  numtype 

xj  i  surf_req  i  i‘Nsurf^Tascent  descent  +  Txmit_recv^  if  numtype  >  1 
x  ■<—  surf_req  ■  Nsurf  (Tascent_deScent +  TXmit_recv)  otherwise 


!  =  (0.591  0)  hr 


Check  against  search  time: 


;T*»arcb  “  3.81  hr 


If  excursion  time  is  unreasonable,  vehicle  altitude  and/or  number  of  fixes  may 
need  to  be  adjusted.  If  necessary,  override  with  estimate  based  on  search  time? 


4.  Prosecution  Time  (for  identification) 


IMM-25 


Number  of  ID  attempts: 


NIA  :=[NM-(l-n)  +  Xi  nm '  W  searcharea  Lsearchareaj  * 


NIA  =  27.227 


Identification  time  (per  attempt):  t 


0.5Dtrack‘2 


Tmine  ID  —  1.693min 


Assumptions  (state  if  formula  changed): 

1.  Typical  prosecution  will  involve  one  vehicle  transiting  about  half  the  track  distance,  including  both 
horizontal  and  vertical  distance  to  the  contact  from  the  search  track. 

2.  Multiply  by  2  for  return  to  place  in  formation. 

3.  Prosecution  speed  set  in  Section  I.C.1;  can  be  adjusted  to  match  overall  system  mission  time  (see 
sub-section  5  below). 


Total  identification  time: 


Tprosecute NIA'Tjjjjjie id 


T  prosecute  —0.76 8hr 


Prosecution  time: 


IDSensors  :=  submatrix(payload , 4, 4, 3, 6) 


(for  each  vehicle) 


ID_Sensors  =(0  "ID-LOW”  0  0) 


Tprosecute  :=  for  i  e  1  ••  numtype 

Xjti  ^  Tprosecute  if  ID_Sensors  |(i  ^  0 


Tprosecute  —  ( 0  0 .768)  hr 


5.  Mission  and  Endurance  Time 


Estimated  vehicle  mission  times: 


TmiSsion_vch_est  =  (5.001  5.179)  hr 


Review  these  times  to  ensure  they  fit  the  system  CONOPS.  For  example,  if  the  system  is  intended  to  search  as  a  unit, 
then  the  mission  times  for  each  vehicle  type  should  be  dose.  In  reality,  vehicles  with  special  assignments  (like 
surfacing  or  prosecuting)  may  speed  up  or  slow  down  to  regain  position.  These  cases  may  be  somewhat  accounted  for 
by  adjusting  (he  prosecution  speed  for  the  ID  vehicle(s)  (Section  1.C.1).  Remember  that  this  will  effect  the  amount  of 
energy  required  by  that/those  vehicles  as  computed  in  the  AUV  Design  Module. 


Total  mission  time  for  system: 


:h_est) 


T  •  •  179hr 

f1  mission  iyni 


Required  vehicle  endurance  time  (same  for  each  type): 

T  endurancereq :=  ^  ■5-ma>^Tmjssjonvej)est^ 

Include  margin 


^endurancereq  “  7.768hr 


III.  AUV  DESIGN  MODULE 

Individual  AUVs  are  designed  in  separate  .mcd  files  that  reference  the  System  Model  for  inputs. 
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AUV  DESIGN  MODULE 


Model  Description 

The  AUV  Design  Module  is  a  sub-components  of  the  System  Model,  and  is  used  to  design  each 
vehicle  type.  The  modeling  approach  is  derived  from  the  MIT  13A  SSN  Math  Model,  a  submarine 
design  tool  based  largely  on  parametric  studies  performed  by  CAPT  Harry  Jackson,  USN  (Ret). 


Constants  Caution:  constant  are  carried  into  this  mode!  through  the  reference  links  as  well;  be 

sure  to  avoid  conflicts  by  check  System  Model  "Constants,,  section. 

lton  :=  22401b 

fcurve  ~  1*176 


80 


I.  INPUTS 


UPDATE  REFERENCE  LINK  PATH  -  DELETE  LINK  AND 
INSERT  NEW  ONE  (USE  "RELATIVE  LINK"  OPTION) 


Enter  number  corresponding  to  vehicle 
being  modeled  in  this  worksheet  (i.e. 
for  first  column  of  numbers,  enter  "1") 


0  Reference: C:\My  Documents\MIT\Thesis\Modeling\Master\System  Model  -  Master.mcd(R) 


W scnsors  =  (20.3  7.175)  lb 

w  •=  W 

¥V  sensors  sensors, 

l  >v 

Vscnsors=(924  718.4) in3 

V  ■=  V 

v  sensors-  v  sensors 

l  ,v 

^sensors  =  (  1 39.4  41)  watt 

P  *=P 

1  sensors  ‘  A  sensors, 
l,v 

Wnav  =  (9.969  20.55)  lb 

w  •=  w 

vv  nav  *  vv  nav, 
l,v 

Vnav  =  (  146.5  719.8)  in3 

V  ■=  V 

Vnav  *  Vnav)  y 

Pnav  =  (22.95  24.25)  watt 

P  *=P 

r nav *  1  nav, 

l,v 

Wcomms  =  (2.5  1.5)  lb 

w  •=  w 

vv  comms  •  vv  comms  ^  y 

Xjomms  =  (61.7  37)  in3 

V  •=  v 

v comms  *  v comms, 

1  ,v 

Pcomms  =  (l2  9)  watt 

P  ■=  p 

r  comms  '  1  comms  {  ^ 

Wcomputer=(4  2)  lb 

^computer*-  ^computerj  v 

vc0mput„=  (300  75)  in3 

^computer Ycompute^  y 

Pcomputcr=(40  15)  watt 

r computer*  *  compute^  y 

^  watt -hr 

7 battery  =  (40.824  40.824)  ib 

Y battery  *“  Ybattery(  v 

watt*  hr 

Pbattery  ~  (5097  5097) 

ft3 

Pbattery*-  P  battery  [  ^ 

Texcursion=  (0-591  0)hr 

1  excursion  1  excursion  v 

prosecute”  (0  0.768)hr 

^prosecute  *—  ^prosecute^  v 

Power  Requirements 

1.  Initial  Power  Estimates 

Mission  time  (estimated  in  System  Model): 

Te„d„ta,-,ce.C7-7(>8hr 

Hotel  power  (based  on  payload  input): 

P HotelReq  *  ^sensors  Pnav  ^comms  ^computer  ^HotelReq 

^HotelReq  pHotelReq'^endurance  req 

^HotelReq 

2 14. 35  watt 
1.665kW-hr 
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Propulsion  power  estimate: 


2.  Propulsion  Power 


Motor  selection: 

^PropPeakest ^Prop  es^^transit) 

Used  to  guide  motor  selection;  use  max 
sustained  speed  (e  g.  transit  speed,  burst 
speed,  etc.) 

Est.  peak  propulsion  pwr: 

j?PropPeak_esi  =  3.21  lhp 

Max  vehicle  diameter: 

^MotorRating  •”  3“P 

Select  motor  power  rating  using  peak  propulsion 
power  estimate  (left).  Check  Vmax  in  Section  V.< 
to  ensure  it  is  sufficient  (i.e.  greater  than  all 
required  speeds). 

^motor 

Enter  motor  diameter  corresponding  to  power 
rating.  Must  be  less  then  max  vehicle  diameter. 

Power  Volume  Density: 

watt 

Pprop  :=3500— 
fr 

Enter  propulsion  plant  volume  density  (include 
support  systems  and  components) 

Power  Weight  Density: 

watt 

Tprop  :==  40  lb 

Enter  propulsion  plant  weight  density  (include 
support  systems  and  components) 

Checks  (from  MCM  WG  model):  rho  :=  ■?--Q72Ft 

0.2&W 


rho  =  0.257 


ft 

kW 


—  =  3889 
rho 


watt 


gamma 


7.61b 

0.2&W 


gamma  -  27.143' 


Jb_ 

kW 


1  _  _  .  watt 

- =  36.842 - 

lb 


gamma 


3.  Energy  Source 

Estimated  required  energy: 

Installed  energy: 

Battery  specific  energy: 
Battery  energy  density: 


^Missionest  •”  ^HotelReq  Eprop_est 


EMissionest  —  5.98kW-hr 


^Installed  —  9.5kW*hr 


Ybattery  ”  40.82 


watt -hr 

lb 


P  battery  —  5097 


watt -hr 


B.  Payload  Weight  and  Volume  Inputs 


1.  Payload  Weights 

W  sensors  =  20.31b 

wnav=  101b 

Wcomms  =  2.51b 


W  computer  4  lb 


2.  Payload  Volumes 

Vse„s„rs=  0.535ft3 
Vnav  =  0.085ft3 
Vcomms  =  0.036ft 
^computer  =  0.174ft3 


C.  Other  Inputs 

Internal  Structure  and  Arrangement 

Internal  Structure  Factor  SF  :=  0.2 

Volume  Packing  Factor  (Dry  Hull)  PFdry  :=  1.0 
Volume  Packing  Factor  (Wet  Hull)  pFwet  :=  0.1 


Internal  structure  volume  as  fraction  of  payload  volume 


Applied  to  dry  volume  subtotal  to  account  for  component 
spacing,  free  floods,  growth  margin,  etc. 


Applied  to  wet  volume  subtotal  to  account  for  component 
spacing,  free  floods,  growth  margin,  etc. 


Ballast  Factor 


Reserved  ballast  volume  as  fraction  of  pressure  hull  volume; 
assumed  to  be  for  "hard"  variable  ballast  tanks. 
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II.  VOLUME  REQUIRED 

A.  Preliminary  Volumes  Calculations 


vbattery  • 


■^Installed 
P  battery 


^propulsion  *— 


rMotorRating 

Pprop 


Vbatteiy=  1.864ft3 
^propulsion  =  0.639ft3 


B.  Dry  (Pressure)  Hull  Volumes 

Payload  and  other  vehicle  components  for  pressure  hull:  Vnav  =  0.085ft3 

Select  appropriate  components  from  Sections  I.B.2  and  II A  _  .  .  3 

Ensure  following  equations  include  appropriate  items.  computer — 

^battery  =  1 -864ft3 

Vpr0p„,si0n  =  0.639ft3 


Standard  pressure  hull  items: 

Vdry_intemal_structure  :=  SF'(Xiav  +  Computer  +  Vbattery  +  Vpropulsion)  Vdryjntemal_structure  =  °‘552ft 

Pressure  Hull  Volume: 

VpH  :=(1  +  PFdry)  (Vnav  +  Vcomputer+  Vbattery  +  Vpropujsjon  +  V^jntemai_stnictUre)  '' 

C.  Wet  Hull  Volumes 

Payload  and  other  vehicle  components  for  wet  hull: 

Select  appropriate  components  from  Sections  I.B.2  and  1  LA 
Ensure  following  equations  include  appropriate  items. 

Standard  wet  hull  items: 

Xvet_intemal_structure  *=  (^sensors  Xomms)  Xvet_intemal_structure 

Vballasttank  :=  BF- VPH  Vhallast  lank  =  0.663ft3 


Vsens0rs  =  0.535ft3 
vc0mms  =  0.036ft3 


Wet  Hull  Volume: 

VwH  :=(1  +  PFwet)-(Vsensors  +  Vcomms  +  VwetjnIema]_structure  +  y>allast_tank) 


6.627ft3 


=  1.482ft3 
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D.  Everbuoyant  Volume 


veb  VpH  4-  Vsensors  +  Vcomms  4  Vwet  jnteraai  structure  +  ^ballast_tank 

E.  Submerged  Volume  and  Displacement 

Assumes  "hard"  ballast  tanks,  i.e.  no  change  in  displacement  for 
submergence  —  only  weight  is  changed. 

As  :=  Vs-psw 

F.  Required  Envelope  Volume  and  Displacement 

Yenvr  :=  VPH  4  VWh  Appendages  (i.e.  control  surfaces,  antennas,  etc.)  are  not  included. 
A  envr  *=  Xenvr*  P  SW 


Veb  =  7.975ft3 

Vs  =  7.975ft3 
As  =  510.3731b 

Venvr  =  8.109ft3 
Aenvr=  518.9961b 


111.  ENVELOPE  VOLUME  AVAILABLE 

A.  Spin  a  Hull: 

Based  on  the  volume  requirements  calculated  in  Section  II,  select  L,  D,  length  of  parallel  mid-body,  and  forward  &  aft  shape  factors. 


Select  D: 
Select  L/D: 


Dimensions: 

Checks: 


D  s  21in 
LOD=  6 
L:=  LODD 


Optimum  =  6 


Constraints:  Based  on  user  entries  in  AUV  System  Model 

and  component  sizes 

Dmjn  •=  niax(Dmjn ,  Dmotor)  (ifet |8 illfl; 


Lmaaj  v  =  20  ft 


L„ax  :=  iffnumtype  >  1 , Lmax, ,  v,Lmax)  E* =20ft 


Dcheck:=  il[(D  <  Dmax  a  D  >  Dmin),"OK" , "RESIZE"] 
Loheck-  >t(L  S  4nax>  "OK"  ,  "RESIZE") 


Use  following  section  to  adjust  nose,  tail,  and  parallel  midbody  lengths. 


Entrance: 

Tjf  :=  2.25  Optimum  =  2.25 

Run: 

rja:=2.75  optimum  =  2.75 

Nose  length: 

Lf  :=  2.4  D  Optimum  =  2.4*D 

4  =  4.2ft 

Tail  length: 

i-(64)d 

4  =  6.3ft 

Parallel  midbody: 

Lpmb  :=  (LOD-  6)-D 

o 

II 

.o 

I 

Length  :=Lf  +  L,+  Lpmb 

Length  =  10.5ft 

B.  Volume  Calculations  to  Support  Arrangement: 


1.  Entrance:  Lf^  4.2ft 


yfl(xl)  :=  1 


NTiflTlf  xl:=0-ft,.l-ft..Lf  +  Lpmb 

Lf-xiyf  D  , 

Lf  I  2  offf(xl)  :=  iff  xl  <  Lf,yfl(xl) 


2.  Run: 


L,  =  6.3ft  xl:=0-ft,.lft..L 


ya(xl)  :=  1 


xl-(Lf+  L(>mb)T°  D 


3.  Total  Ship:  0fft(xl)  :=  if(xl  <  Lf  +  Lpmb, offf(xl),ya(xl)) 


3  4  5  6  7 


9  10  11 


4.  Total  Ship  Volume 


Vtot  :=  offt(xl)  -rcdxl 


Vtot  =  1 6.602ft 


V  —  V 
Venva  vtot 


^enva  PSW'Xo 


Aenva=  1062.553b 


5.  Tail  Cone  angle  (measured  from  the  axis  of  rotation  to  to  the  tangent  at  the  stern).  Greater  than  18  degrees 
probably  considered  a  full  stern. 


=  15.814deg 


i+  2[° 

24 


6.  Total  Prismatic  Coefficient 


(DY 

71*  —  L 

U  J 


Cp  =  0.657 
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7.  Forward  Prismatic  and  Wetted  Surface  Area  Coefficients: 


offt(xl)  dxl 


n— -2.4 
4 


2-offt(xl)-7idxl 


Cpf  =  0.7127 


8.  After  Prismatic  and  Wetted  Surface  Area  Coefficients: 


offi(xl)  -ndxl 


,2-3.6 

4 


2-offt(xl)-*dxl 


Cpa  =  0.6205 


9.  Available  Envelope  Displacement  and  Wetted  Surface  Area: 


Cwsf  =0.81 89 


CwSa  =  0.7333 


Kl:=6-2.4Cpf-3.6Cpa 
K2  :=  6  —  2.4'Cwsf-  3.6,CWsa 
WS  :-7t*D2  (LOD-K2) 


WS  =  44.309ft 


10.  Envelope  Volume  Balance. 

Outboard  volumes  are  not  included  in  the  hull  sizing. 


Vcnvr=  8.109ft 


Venva=  16.602ft 


Ensure  that  available  volume  exceeds  required  volume.  A  +/-  1%  error  bound  is  KM|||| 

preferred,  but  most  AUVs  will  require  excess  volume  to  achieve  required  buoyancy:  BISII 

If  Errv  <  0,  then  available  volume  is  too  small,  so  increase  envelope  volume. 

If  Errv  >  0,  then  available  volume  is  too  large,  so  decrease  envelope  volume  unless 
restricted  by  weight. 


87 


IV.  WEIGHT  AND  BUOYANCY 

A.  Weight  Estimation 


NOTE:  This  section  not  important  if 
size  of  vehicle  is  known.  The  powering  calcs 
are  based  on  size,  not  weight.  Cost  is  determined 
primarily  from  payload  components  (?). 


1.  Lightship  Weight  (excluding  fixed  ballast) 


Traditional  SWBS  Groups 
Hull  Structure 
Propulsion  Plant 
Electrical  Plant 
Command  and  Control 
Auxiliary  Systems 
Outfit  and  Furnishings 
Mission  Payload 


AUV  Components  Group  Number 
Structure,  Mountings  1 

Motor,  Propulsor,  Shaft,  Gears,  Fins  2 

Batteries,  Wiring,  Junctions  3 

Controllers,  Recorders  4 

Ballast  Equip,  Hydraulics  5 

n/a  6 

Sensors,  Navigation,  Comms,  Computer  7 


Required  envelope  and  submerged 


displacements  (from  above) 


Group  1  fraction  ofavailableenvelopedisplacement: 
Group  2  weight  fraction  (from  above): 

Group  3  weight  fraction  (from  above): 

Group  4  fraction  of  submerged  displacement: 
Group  5  fraction  of  submerged  displacement: 
Group  6  fraction  ofsubmeraed  displacement: 
Group  7  (from  spreadsheet): 


Wlfrac:= 

.15 

W2ftac:= 

-l 

Yprop 

^3frac*~ 

Y  battery 

^4frac*~ 

.01 

W5ftac*= 

,02 

W  6frac*~ 

0 

W 7est W senson;  +  +  Wcomms  +  Wcomputer 


ESTIMATED  VALUES 

ACTUAL  VALUES  Enter  if  known 

W  lest  :=  W  i fi-ac  ^enva 

Wlest=  159.3831b 

W,  :=  W lest 

^2est :==  ^2frac  ^MotorRating 

W2est  =  55.9261b 

W2  :=  W2est 

^3est  ^3frac -^Installed 

W3est  =  232.70ab 

W3:=W3est 

^4est  "^4 fracas 

W**- 5.1041b 

W4:=W4est 

^5est  ^5frac^s 

W5est  =  10.2071b 

W5  :=W5est 

^6est  *“  ^  6  fracas 

Wfet  =  01b 

W6:=W6est 

W7est  =  36.7691b 

W7  :=  W7est 

Lightship  weight 
(excl  fixed  ballast): 


WAi  :=  Wj  +  W2  +  W3  +  W4  +  W5  +  W6  +  W7 

Check: 
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2.  Ballast  Requirements 

Positive  Buoyancy  as  fraction  of  submerged  displacement:  Bfrac:=  0.01 


Variable  ballast  volume: 

Ballast  tank  volume  (from  above): 

Vballastjank  =  0.663ft 

Vvb  :=  0.9- Vbaiiast  tank 

Vvb  =  0.596ft3 

Wvb  *=Vvb'PSW 

Wvb  =  38.1731b 

Negative  buoyancy  check: 

®neg  :=  Bpos  "  ^vb 

Bneg  = -33.071b 

R  ~B"eg 

°frac  neg*~ 

As 

Bfracneg=  0.065 

Bnegchec|t : 

=  if(Bfrac  neg>  Bfrao "OK"  , "NOT  OK") 

Weight  Summary 

Wls 

:=WA1  +  Wlead  Aa  :=  W|s  | 

505.271b. 

Wfl: 

:=  Wls  +  Wvb  (V 

Vfl  =  543.4431b 

Speed  range  of  interest:  V  —  0,  .1 ..  15  ^  lOknt ; 

Sections  A  through  C  present  different  methods  of  calculating  the  drag 
coefficient.  User  can  select  method  in  Section  E. 

A.  Drag  Coefficient  (Jackson  Wetted  Surface),  CD_WET1 

1.  Resistance  calculation  parameters: 

Vknt 

Reynolds  Number:  RN(V)  :=  L - 

vsw 

Wetted  Surface  (previously  calculated):  WS  =  44.309ft2 

For  ships,  this  is  typically  .0004.  CAPT 

Correlation  Allowance:  Ca  ;=  .0004  Jackson's  notes  indicate  that  C  a  should  be 

.0002  -  .0015  for  submarines. 


2.  Frictional  resistance  coefficient:  Cf(V)  := - 1 - 

(log(RN(V))-2)2 


3.  Residual  drag  coefficient:  The  following  equation  for  (Cf  +Cr)/Cf  was  developed  by  Hoemer  using  the  fact 

that  the  after  end  of  the  submarine  has  a  large  effect  on  the  form  coefficient  (See 
Reference  1 ) 


Cftf=  1-37 

Cr(V)  :=  CMCf<V)  -  Cf(V) 


4.  Appendage  drag  coefficient: 

Check  against  alternative  methods: 

1 .  Rule  of  thumb  for  submarines  is  that  the  non-sail  appendages 
have  a  A*Cd  ("App"  below)  value  equal  to  approximately  L*D/1000. 

2.  Percentage  of  total  resistance  coefficient  w/out  appendages. 


Estimate  appendage  area  as  a  fraction  of 
wetted  surface  area  and  use  0.006  for 
appendage  drag  coef. 


Compare  to: 

1  •  App  :=  —  App  =  0.0 1 84ft2 

1000 

2-  Cafi(V)  :=  WS.(Cf<V)  +  Cr(V)  +  Ca) 

CappI0%(V)  :=  0.10Caf/V) 
Cappio-z/lO)  =  0.0190ft2 


5.  Total  drag  coefficient: 

CD  WETl  (V)  :=  Ca  +  Cf(V)  +  C,(V)  +  Capp-fapp 


fapp:=0.05  Capp  :=  .006 

Capp-fapp- WS  =  0.0133ft2 


B.  Drag  Coefficient  (Hoerner  Wetted  Surface  Method),  C  d_wet2 


C.  Drag  Coefficient  (Hoerner  Frontal  Area  Method),  C  DFROnt 
Total  drag  coefficient  (bare  hull  only): 

CD_BH_FRONT(V):=Cf(V)'  +  4'5  +  21^ CD_BH  FR0NT^^-  j  =  0.063 

D.  Resistance 

1.  Jackson  Wetted  Surface  Method 

RyjVETl (V)  :=  0-5'PSW,WS*Q5_WETlW(V,lmt)2  RT_WET1 

2.  Hoerner  Wetted  Surface  Method  (with  Jackson  method  for  appendage  drag) 

Bare  hull: 

rbh_wet2 (V)  :=  O.Spsw-WS.CD_BH_WET2(V)-(V-knt)2  Rbh_wet2 

Appendage: 

Rapp(V)  :=  0.5  psw •  Capp- fapp- WS  ■  (V- knt)2  Rapp^— J  =  1355'bf 

Total: 

RT_WET2  (V)  :=  RBH_WET2(yi  +  RaPpOO  RT_WET2 

3.  Hoerner  Frontal  Area  Surface  Method  (with  Jackson  method  for  appendage  drag) 

Bare  hull: 

71*  D2  2 

RBH_FRONt(V)  :=0-5  psW-^J— CD_BH_FRONT(y)-(Vknt)2  RbH_FRONT 

Appendage: 

rapp(^0  0.5  psw'Capp4pp'WS-(V- lent) 

Total: 

rt_front(V)  :=  rbh_front(^0  +  rapp(^0  rt_front 
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E.  Powering  Requirements 


Propulsive  Coefficient: 
Motor  efficiency: 


PC:=  0.85 

motorjv  *=  0.85  Veff 1  Oknt 
0  motor(  V)  :  =  r|  motor_V  *  (v*  kilt-  Veff 


Enter  efficiency  and  corresponding  speed 


Accounts  for  motor  inefficiency  at 
lower  speeds. 


Resistance  calc  method: 


Rt(V)  :=  Rt_weti  (V) 


Enter  desired  method  from  previous  section. 


Brake  power  (includes  estimated  PC  and  motor  efficiency): 


BP(V)  := 


RT(V)-Vknt 


550 


ft-lbf 


sec-hp  ) 


\vc-r\n 


ator(Y) 


VI  :=4,6..  10 


BP(V1)  = 


0.254 

0.607 

1.127 

1.823 


kW 


F.  Powering  Results  v_plot  :=  1,1.1..  12 


§  BP(vjlot) 


1 

m 


Speed-Power  Curve 
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G.  Maximum  Speed  (Submerged) 


a  :=  10  (initial  estimate  for  root  finder) 

^MotorRating  “  2237.05  lwatt 

vmax :=  root(BP(a)  -  PMotorRating  >  a)-knt  Vmax  -  10.995knt  Vsearch  =  6knt 

Re-select  motor  size  to  achieve  maximum  Vtnmsit  =  lOknt 

required  speed  (usually  Vsearch  or  Vtransit). 

H.  Optimum  Speed  (Submerged) 

Optimum  transit  speed  is  that  which  uses  one  half  the  power  of  the  hotel  load:  Ptransit  =  1/2  *  P  hote, 
BPoptimum  :=0.SPHotelRcq  BPoptimum  =  107.175watt 

Following  formula  determines  the  speed  at  which  the  desired  (i.e.  ideal)  transit  power  is  achieved: 
b  :=  10  (initial  estimate  for  root  finder) 

v0ptimum  :=  root(BP(a)  -  BPoptimum ,  a)-knt  Voptimum  =  2.669knt  For  infomra.ion  only 


I.  Energy  Consumption  and  Endurance  Calcs 
Endurance  as  a  function  of  speed: 


Endurance  (V)  := 


installed 


BP(V)  4-  PnotelReq 


Endurance  V) 
hr 
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Endurance  based  on  mission  profile: 


System  endurance  requirement: 

Time  margin  (incorporates  adjustment  from  System  Model  to  set  all  vehicle  endurances  equal): 


^margin  •“  *  cnduranccrcq^  v  *  transit  +  *  search  *  excursion  *  prosccutej 


Energy  consumption: 


p  T 

transit  •“  Drl  ^  1  ‘transit 

£^,=  1. 094kW.hr 

)'Tstimh 

.  ..bJ0SW**A.t 

Excursion  •“  Drl  ^  1  ‘excursion 

Uio«  =  O.OSlkW.hr 

Assumes  1/2  Vsearch 
during  excursions 

r  n/Vprosccutc  1  T 

^prosecute  Drl  1  1  prosecute 

prosecute  =  OkW-hr 

Assumes  Vsearch  during 
prosecutions 

Emargin' l-68kW.hr 

Assumes  margin  time 
spent  at  Vsearch 

Epropuisionjotal  :=  ^transit  +  ^search  +  ^excursion  +  ^prosecute  +  ^margin  Efropulsionjotal  -  5.168kW-hr 
^Mission  :=  ^Propulsion  total  +  -^UotclReq  j^M***^ 

Compare  to:  =  5.98kW-hr 


^Surplus  ^Installed  ^Miss 


L  t  10  5ft 
D  -  21m 
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Appendix  C 


Effectiveness  Model 


MCM  EFFECTIVENESS  MODEL 


Model  Description 

Include  place  for  description  of  mission 


INPUTS 


Directions: 

IMPORTANT:  Output  files  are  written  at  the  end  of  this  file.  If  a  new  file  is  being  created  using  a  file  for  another 
system,  be  sure  to  change  the  output  file  names  FIRST  so  as  to  avoid  writing  over  the  output  for  the  other  file. 

1 .  Insert  links  for  System  Model  file  and  each  AUV  Design  Module  file  (one  for  each  vehicle  type):  delete 
old  link  first  and  then  re-insert  reference  link  (lnsert\Reference\...  use  relative  link  option). 

2.  For  each  vehicle  link,  make  sure  the  L  &  D  lines  are  inserted  and  the  correct  subscripts  are  used. 

3.  When  any  changes  are  made  to  other  files,  these  links  must  be  updated  by  clicking  once  on  the  link  and 
pressing  F9.  Do  this  for  each  link.  (Be  sure  link  files  are  saved  first.) 


System  Model  Link: 

0  Reference:C:\My  Documents\Mn\Thesis\Modeling\Master\System  Model  -  Master.mcd(R) 
nvch_totai  :=  iff  numtype  >  l,^Tnumveh  ,numveh 


Vehicle  Links  (one  for  each  type): 

0  Reference:C:\My  Documents\MmThesis\Modeling\Master\AUV  Design  Module  -  Master.mcd(R) 


LLj  :=L  LL,  =  10.5ft 


DDj  :=  D  DDj  =  21  in 


0  Reference:CAMy  Documents\MIT\Thesis\Modeling/Case  One\S2  AUV2.mcd(R) 
LL>:=L  LLz  =  8ft  DDj  :=  D  DD2  =  12in 

Add  additional  links  for  each  AUV  type 
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MOE-MOP  HIERARCHY  Blue  =  MOE  Purple  =  Sub-MOE  Black  =  MOP 


Mission  Time 

Effective  Area  Coverage  Rate 

Multiple  system  parameters  (modeled) 

Mission 

Accomplishment 

Search  Level 
(through  identification) 

Localization  Accuracy 

Clearance  Level 

Multiple  system  parameters  (modeled) 

Navigation  accuracy  (modeled) 

Multiple  system  parameters  (modeled) 

Autonomy 

Lift  Support 

Host  Support 

System  Footprint  (modeled) 

Host  Platform  Requirement(utility  fen) 

Communication 

Reporting  Frequency 

Data  Type 

Reporting  Frequency  (utility  fen) 

Data  Type  (utility  fen) 

Covertness 

Deployment  Phase 

Mission  Phase 

Recovery  Phase 

Platform  Type  (utility  fen) 

Platform  Type  and  Location  (utility  fen) 

Platform  Type  (utility  fen) 
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MOE  WEIGHTS 


This  method  for  establishing  the  MOE  weights  is  based  on  an  Analytical  Hierarchy  Process  technique 
sometimes  called  the  "pairwise  comparison  matrix  method".  Here,  only  the  upper-level  MOE  weights  are 
derived  using  the  matrix  method;  the  sub-MOE  are  assigned  directly  because  there  are  no  more  than 
three  in  any  group  to  compare.  To  obtain  valid  weights,  a  formal  survey  process  should  be  undertaken  to 
extract  the  warfighter's  preferences.  Each  pair  combination  [n(n-1  )/2,  where  n  is  the  number  of  MOE] 
should  be  included  in  the  assessment. 

A  simplified  approach  taken  for  this  thesis  is  shown  here.  The  number  pairwise  comparisons  is  kept  to 
the  minimum  [n-1],  and  all  values  are  assigned  by  the  author. 

Instructions: 

1 .  Place  MOE  in  order  from  most  important  to  least  important. 

2.  Re-order  and  update  indices. 

3.  Enter  comparison  values  for  the  four  F^l 

MOE  Order 


1  Time 

Set  indices: 

Time 

tm  :=  1 

2  Accomplishment 

Mission  Accomplishment 

ma  :=  2 

3  Communication 

Communication 

co  :=  3 

4  Autonomy 

Autonomy 

au  :=  4 

5  Covertness 

Covertness 

cv  :=  5 

97 


MOE  Pairwise  Comparison  Matrix  and  Eigenvalue  Problem 


1 

RI12 

RIb 

ri,4 

RI,5^ 

r  1  1.5 

4 

6 

8  ^ 

RIl2_1 

1 

RI23 

Ri24 

ri25 

0.667  1 

2.667 

4 

5.333 

Rl23_1 

1 

ri34 

RI35 

MOE  = 

0.25  0.375 

1 

1.5 

2 

_  1 

—  1 

_  1 

0.167  0.25 

0.667 

1 

1.333 

RIl4 

ri24 

ri34 

1 

RI45 

^0.125  0.188 

0.5 

0.75 

1  J 

RI15_1 

R'25-1 

RV1 

Rl45_1 

1 J 

1 

( 


eigenvals(MOE)  = 


5 

0 

0 


max_ev :=  ma>(eigenvals  (MOE) )  max_ev  =  5 


Inconsistency  ratio 
(must  be  less  than  0.01) 


Re(max_ev)  -  rows(eigenvals(MOE)) 
rows(eigenvals  (MOE)) 


IR  =  0 


Weights  obtained  from  eigenvector  associated  with  maximum  eigenvalue: 


eigenvec  (MOE,  Re(max_ev))  = 


f  0.803^ 
0.535 
0.201 
0.134 


V  0.1  ) 


sum  ev  :=  eigenvec  (MOE,  Re(max_ev)) 


sum  ev  =  1.774 


Normalized  MOE  weights: 


MOE_wt:= 


eigenvec  (MOE,  Re(max_ev)) 
sum  ev 
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TIME  MOE 


MOE  Description 

The  Time  MOE  represents  the  time  required  for  the  AUV  system  to  accomplish  the  assigned  mission 
objectives. 


Sub-MOE  Description(s) 

Effective  Area  Coverage  Rate  Ratio  of  the  total  search  area  to  the  total  amount  of  time  required 

to  complete  the  mission  objective(s),  from  AUV  system 
deployment  to  recovery.  Includes  time  spent  in  the  search  area 
plus  transit  time  to/from  the  search  area. 

Alternate: 

Total  Mission  Time  The  total  amount  of  time  from  AUV  system  deployment  to 

recovery.  Includes  time  spent  in  the  search  area  plus  transit  time 
to/from  the  search. 


Weights 

Time  MOE 


Area  Coverage  Rate 


Contributing  System  Parameters  (MOP) 


Number  of  tracks 

ii 

2 

Track  spacing 

Dtrack  =  571.429/d 

Runs  per  track 

J=  1 

Track  length 

Usearcharca=  3 11111 

Search  speed 

Vscarch-  10. 125ft  sec 

Transit  speed 

^transit  ~  lOknt 

Total  track  run  distance 

dtrack_runs  —  2 1  nm 

Total  turn  distance 

dturos=  1.862nm 

Distance  into  search  area 

<W«s=  lnm 

Distance  out  of  search  area 

degress  =  5  nm 

Distance  to  recharge  point 

^recharge 

Number  of  recharges 

^recharge 

Recharge  time 

T 

1  recharge 

Contributing  Mission  Parameters 

Search  area  dimensions  Lsearcharea=  3  nm 

Wsearcharea=4x  10?  yd 


Estimated  number  of  mines  NM  =  25 
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Relationships 


MOE  Determination  Method:  MODELING 


^mission  =  T  search  +  T^^it  +  Tservjce  +  Texcursjon  =  Ten(jUrance_req 

Lsearcharea  W  se  archarea 

ACR^ffS 


Results 

^mission  "=  Ten{jurance_req 

Lsearcharea  W  searcharea 
ACReff:= - - 


MISSION  ACCOMPLISHMENT  MOE 

MOE  Description 

The  Mission  Accomplishment  MOE  represents  the  estimated  condition  of  the  searched/cleared  area 
after  the  mission  is  completed.  This  MOE  reveals  the  extent  to  which  any  specified  mission  objectives 
were  achieved  or  surpassed. 


Sub-MOE  Description(s) 


Search  Level  (through  identification)  FOR  NON-CLEARANCE  MISSIONS  ONLY.  Cumulative  joint 

probability  of  detecting,  classifying,  and  correctly  identifying  mines 
within  the  specified  search  area.  Also  known  as  "Percent  Search". 

Localization  Accuracy  FOR  NON-CLEARANCE  MISSIONS  ONLY.  Represents  the 

distance  error  between  the  reported  mine  positions  and  the  actual 
mine  positions.  Also  called  "contact  position  error.  For  this 
model,  the  contact  position  error  is  taken  as  a  function  of  the 
system  navigation  error  (%DT).  [Note:  if  determined  by 
post-analysis  or  simulation,  localization  error  could  be  given  as 
Distance  Root  Mean  Squared  (DRMS).] 

Clearance  Level  FOR  CLEARANCE  MISSIONS  ONLY.  Cumulative  joint  probability 

of  detecting,  classifying,  identifying  (optional),  and  neutralizing 
mines  within  the  specified  search  area.  Also  known  as  "Percent 
Clearance".  Note:  Model  is  currently  unable  to  handle  clearance 
missions . 
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Weights 


Mission  Accompiishment  MOE  Wt  Acmp  :=  MOE  wtma 


Search  Level  (through  ID) 
Localization  Accuracy 
Clearance  Level 


Enter  value:  WtsL:=0-6 
Wt  la  :=  1  -  WtSL 
WtCL  :=  if(wtSL=  0,1,0)* 


Contributing  System  Parameters  (MOP) 
Number  of  tracks 
Runs  per  track 
Track  spacing 

Standard  deviation  of  track  keeping 

Characteristic  search  width 


Characteristic  probability  of  detection/classification 


Maximum  acceptable  position  error 
System  Navigation  Error  (%DT) 


N  =  7 


J=  1 


Dtrack=  571.429yd 


a  = 


^15  30  0  0^ 
15  30  0  0 
^15  30  0  0y 


ft 


A  = 


r588  588  0  0^ 
0  0  0  0 
^  0  0  0  0  > 


yd 


B  = 


^0.876  0.9  0  0> 
0  0  0  0 
^  0  0  0  Oj 


max_pos_error  =  30yd 
%DT  =  0.05 


Contributing  Mission  Parameters 


Target  strength  y  =  -30dB 

Bottom  type  BT  =  4 


Water  depth 


davg  =  400ft 


Disabled 
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Relationships 


MOE  Determination  Method:  MODELING 


,  v  /  _M  Y\  Note:  Percent  clearance  just  adds  probability  of 

^search =  U  —  ~  e  )  neutralization 

p  —  ( 1  —  •  I  )  p  p  { 1  —  p”  M 

i  A  R  1  clear “  V1  M7  * r  imm  ’ r  nmm  ‘  ' 1  c  ' 

where  m  = 

l^track 


avg_pos_error  =  0.5max_pos_error 


Results 

p  —  p 

‘search  ‘search 

avg_pos_error  :=  .5*max_pos_error 


AUTONOMY  MOE 

MOE  Description 

The  Autonomy  MOE  represents  the  independence  of  the  system  from  logistics  support  and/or  oversight  for 
guidance  and  tasking.  It  is  expressed  in  terms  of  a  normalized  score  on  a  scale  of  0  to  1 . 


Sub-MOE  Description(s) 

Lift  Support  Amount  of  cargo  space  required  for  deployment/recovery  of  the  system, 

given  in  terms  of  area  (e.g.  sqft) 

Host  Support  Level  of  service  and/or  command  and  control  support  required  during  a  mission. 

This  requirement  is  specified  in  terms  of  discrete  host  responsibility  alternatives 
(e.g.  dedicated  platform,  remote  command  and  control,  none,  etc.) 


Weights 

Autonomy  MOE 


Lift  Support 


Host  Support 
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Contributing  System  Parameters  (MOP) 


Number  of  vehicle  types 
Number  of  vehicles  (each  type) 

Vehicle(s)  dimensions 

Reliability/redundancy 
Recharge  method 

Host-system  communication  method 


numtype  =  2 
numveh  =  ( 1  2 ) 


10.5^ 

f 21 1 

ft 

DD  = 

V  8  J 

V 12/ 

reliability  =  "LOW" 

recharge  =  "NR" 

comm  method  =  "RF-SAT" 


Relationships 

MOE  Determination  Method  MODELING  /  UTILITY  FUNCTION 


Lift  Support  =  Total  System  Footprint 


numtype 

FPsys=  ^  fstow.-n«mvehiFPveh. 
i  =  1 


where  FPveh  =  [sqft] 

^  is  stowage  multiplier 


Host  Support 


None  required  1.0 

Command/control  only  (remote)  0.7 
In-theater/dedicated  0.0 


Results 

L  :=  LL  D  :=  DD 


f 

F^sys  •” 

V 


numtype 


numtype 

>  1,  ^  numveh  j  iL^Dpnumveh  Lj-D! 

i  =  i  J 


Note:  Footprint  calculation  does  not 
include  any  system/vehicle  stowage 
factors 


Scorehost 


0  if  (reliabilitys  "LOW"  v  commmethods  "AM"  v  comm_method=  "RF-LOS"  v  recharges  "HOST") 
0.7  if  comm  methods  "RF-SAT" 


1.0  otherwise 


Scorehost 
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COMMUNICATION  MOE 

MOE  Description 

The  Communication  MOE  represents  the  system's  capability  to  receive  and/or  transmit  information  from/to  a 
host.  It  is  expressed  in  terms  of  a  normalized  score  on  a  scale  of  0  to  1 . 

Sub-MOE  Description(s) 


Reporting  Frequency 


Frequency  of  transmissions  from  system  to  host  or  vice 


Data  Type 


Low:  CAD/CAC,  system  position/status,  contact 
positions,  etc.  Also,  command  and  control-related 
information  from  host; 

High:  Post-processed  data  intended  for  human 
interpretation  (e.g  sonar  imagery  or  "snippets") 


Weights 


Communication  MOE 


WtCOMM  :=  MOE^o 


Reporting  Frequency 


Enter  value:  Wt^  :=  0.3  Riamtfc 


Data  Type 


WtDT  ^1-WtRp 


Contributing  System  Parameters 


Host-system  communication  method 


comm  method  =  "RF-SAT" 


Reporting  frequency 


reportfreq  =  "PRD" 


Relationships 


Data  Type  (Content) 

High  Content  1 .0 
Low  Content  0.7 
None  0.0 


Reporting  Frequency 

Continuous  1 .0 

Periodic  0.5 

None  0.0 


Results 


e  :=  0  if  comm_method  =  "NR" 

0.7  if  comm_method  =  "AM" 
1.0  otherwise 


®rePort_freq'=  0  if  report Jreq  =  "NR" 

0.7  if  report  freq  =  "PRD" 
1.0  otherwise 


Score^ajype  -  1 


Scores  froq=  0.7 
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COVERTNESS  MOE 


MOE  Description 

The  Covertness  MOE  represents  the  extent  to  which  the  system's  presence  and  efforts  are  difficult  to  detect. 
It  is  expressed  in  terms  of  a  normalized  score  on  a  scale  of  0  to  1 . 


Sub-MOE  Description(s) 
Deployment  Phase 


Mission  Phase 


Recovery  Phase 


Ability  to  avoid  detection  during  deployment  phase  of 
operation. 

Ability  to  avoid  detection  during  mission  (search/clearance) 
phase  of  operation. 

Ability  to  avoid  detection  during  recovery  phase  of  operation. 


Weights 

Covertness  MOE 


Wt  cvrt  * —  MO E_wtcv 


Deployment  Phase 
Mission  Phase 
Recovery  Phase 

Check  sum: 


Enter  value: 

WtDP:=0.4 

Enter  value: 

WtMP  :=  0.25 

Enter  value: 

WtRp  :=  0.35 

Chk:=i£(Wt 

DP  +  Wtwp  +  Wt, 

=  1 ,  "OK"  ,  "Weights 


must  sum 


to  1.0"  ] 


Contributing  System  Parameters 

Clandestine  delivery  method  cland_deliv  =  "AIR" 

Clandestine  recovery  method  cland_recov  =  "SURF" 

Host  requirement  (from  Autonomy  MOE) 


Relationships 


Deployment  Platform  Type  Recovery  Platform  Type  Mission  Phase  Platform 

Type  &  Location 


None  Reqd 

1.0 

None  Reqd 

1.0 

None  Reqd  1 .0 

Sub 

0.9 

Sub 

0.9 

Satellite/air  link  0.9 

Air 

0.3 

Air 

0.3 

Sub  0.6 

Surf 

0.0 

Surf 

0.0 

Surf  0.0 
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Results 


x  :=  clanddeliv 
Score^eploy 


x=  "AIR" 


jScoreaepioy  ~  0.3 

S  <:  •  - :■«  V- i:  :  i  i 


y  :=  cland_recoy  =  "SURF" 


2  :=  Scores 


z  =  0.7 


0  if  x=  "SURF"  Scorerecov:= 

0  if  y  =  "SURF"  Scoremjssi0n  := 

1.0 

N 

II 

0.3  if  x  =  "AIR" 

0.3  if .y  =  "AIR" 

0.9 

ifz^OAz^l 

0.9  if  x=  "SUB" 

0.9  if  y  =  "SUB" 

otherwise 

1.0  otherwise 

1.0  otherwise 

0.6  if  x=  "SUB" 

0  otherwise 

■  Scorercc0v  — 0 


£  ;  v;; . 

I: SCO r£5  tiiiss ion  “  0:9 


Note:  assumes  sub  will  serve  as  mission 
host  if  sub  is  the  delivery  platform 
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SUMMARY 


MOE  Values: 


,  =  7.65 8hr 


2 

ACR*^  0.774— 
hr 


Psearch-  0.977 


avg_p°s  error  =  15  yd 
FPsys  =  55.125ft2 
Scorehost  ~  0.7 
Score  rep0rt_freq=  0.7 

Score  datatype  ”  ^ 

Score  deploy  =  0.3 

Score  recov  0 

Score  mission  =  0.9 


MOEResults  := 


^mission 

hr 

ACRcff 

2,  -1 
nm  -hr 

Psearch 

avg_pos_error 


yd 

PPsys 


Scorehost 


Score  report_fireq 
Score  data_type 
Scoredeploy 

Score  recov 
Score  mission 


Output  link 
not  shown 


MOE  Weights: 

Wt-fiME  "  0.453  WtACR  =  1 

WtACMP  =  0.302  WtsL  =  0.6 

WtLA  =  0.4 

wt  atmy  =  0.075  WtLR  =  0.25 

WtHR  =  0.75 

WtCOMM  =  0.113  WtRF  =  0.3 

WtDT  =  0.7 

WtcvRT  =  0.057  WtDP  =  0.4 

WtMP  =  0.25 
WtRP  =  0.35 


Outpute  link 
not  shown 


Ouput  link 
not  shown 
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AUV  MCM  System  OMOE  Spreadsheet 


System  name:  SI  -  Single  Vehicle,  Multiple  Sensors 


RED  =  pre-defmed  weights 
Capability 


BLUE  =  calcs. 
MOP 


Threshold 


MAGENTA =  Model  Score 

MOP 

Goal  Attained 


0.217  0.217 


0.600  |Search  Level 

0.612 

0.94 

1 

0.977 

0.302 iMission  Accomp  1 

0.400|Localization  Accuracy 

50 

5 

15 

0.678 

O.OOOjClearance  Level 

1.000  Check  =  1 .000 

0.778 

ZZ1 

1.000 

1 

0 

0 

0.2501  Lift  Support 

1 

500 

50 

18.38 

0.07 5 1 Autonomy  j 

0.250 

0.750|Host  Support/Oversight 

1.000 

ZZ1 

Dedicated 

None  Reqd 

0.00 

0.000 

1.000  Check*  1.000 


0.300| Reporting  Frequency 

None 

None 

Continuous 

High 

0.70 

1.00 

0.113|Communication  j 

0.910 

0.700 1 Data  Type 

1.000  Check  =  1.000 

0.700 

- 1 

1.000 

0.400| Deploy  Phase 

_ 1 

Surf 

None  Reqd 

0.30 

0.300 

0.057 1  Covertness  | 

0.250 [Recovery  Phase 

1 

Surf 

None  Reqd 

0.00 

0.120 

0.000 

0.350|Mission  Phase 

- 1 

Surf  (ded) 

None  Reqd 

0.00 

0.000 

1.000  Check  =  1 .000 


1.000  Check  =  1.000 
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Appendix  D 


AUV  Sub-system  Databases 

The  databases  shown  in  this  Appendix  are  accessed  through  the  Excel  link  in  the  System 
Model.  In  general,  they  contain  weight,  volume,  and  electric  power  characteristics  for  a  catalog 
of  AUV  sub-systems.  In  the  interface  sheet  of  the  Excel  link,  the  user  configures  each  AUV 
by  selecting  the  proper  designation  from  among  the  options.  The  corresponding  information 
is  then  extracted  from  the  databases  using  lookup  features  and  passed  to  the  System  Model 
(i.e.  for  the  AUV  Design  Module).  The  items  and  numeric  values  in  these  databases  should  be 
observed  with  caution,  as  they  were  derived  from  various  sources  and  have  not  been  validated. 
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SONARS  DATABASE 


Source:  MCM  Future  Systems  Study  Workbook 

Comments:  ALS/SAS  data  for  wide  beam  only  (meant  for  deeper  water,  i.e.  200+  ft);  wt/vd/pwr  given  for  arrays  and  electronics,  but  not  signal  processing 


Sonar  Type 

Sensor  Desig 

Min  Vehicle  Diameter 

Wt 

Vol 

Power 

in 

lbs 

cu  in 

w 

Ahead  Looking  Sonars  (ALS) 

ALS-4 

4.875 

9.1 

396 

87.3 

ALS-7 

7.5 

10.6 

475 

91.6 

ALS-12 

12.75 

14.2 

617 

128.6 

ALS-21 

21 

20.3 

924 

139.4 

ALS-36 

36 

37.3 

1726 

142.7 

ALS-54 

54 

68.2 

3160 

174.2 

Sythetic  aperature  sonars  (SAS) 

SAS-4 

4.875 

2.9 

146 

18.9 

SAS-7 

7.5 

4.3 

284 

26.6 

SAS- 12 

12.75 

9.3 

954 

48 

SAS-21 

21 

19.6 

2633 

76.1 

SAS-36 

36 

53.3 

11296 

81.9 

SAS-54 

54 

127.3 

33572 

82.1 

Side-scan  sonars  (SS) 

SS-12 

12 

7.0 

716 

36.0 

SS-21 

21 

14.7 

1975 

57.1 

Note:  must  change  lookup  formulas  in  SysDefn  sheet  if  expanded  past  current  point 

ID  SENSORS  DATABASE 

Source:  MCM  Future  System  WG 

Comments:  Traditional  sensors  listed  here;  see  WG  paper  for  more  advanced  concepts 

ID  Sensor  Type 

Sensor  Desig 

Min  Vehicle  Diameter 

Wt 

Vol 

Power 

Diameter 

Length 

in 

lbs 

cu  in 

w 

in 

in 

Deep  Sea  SS-126C  Video/Lighting 

ID-LOW 

n/a 

0.20 

2.88 

5 

1.26 

2.31 

Benthos  DSC  4000  Dig  Still  Camera 

ID-MED 

n/a 

5.00 

143.14 

12 

4.50 

9.00 

Benthos  DSC  5010  Dig  Still  Camera 

ID-HIGH 

n/a 

7.25 

143.14 

45 

4.50 

9.00 

Note;  can  expand  to  cell  20  without  changing  current  lookup  formulas  in  SysDefn  sheet 
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NAVIGATION  PACKAGE  DEFINITION 


Instructions  for  adding  or  modifying  navigation  packages: 

1 .  Make  entries  in  yellow  section  only.  Gray  sections  are  updated  automatically. 

2.  To  add  a  component  to  a  nav  package,  highlight  the  second  row  of  a  package  (inside  the  framed  box  only),  and  insert  rows  usin< 
the  "shift  cells  down"  option.  Type  the  new  component  designation  number  in  the  4th  column. 

3.  To  create  an  entirely  new  nav  package,  either  replace  an  existing  one  or  insert  cells  as  described  in  item  2  (except  highlight  the 
white  between  the  frames  instead). 


Nav  Suite 


Component  Weight 

Designations  Component  Names  (lbs) 


NAVIGATION  COMPONENTS  DATABASE 

Source,  MCM  Future  SyMerr*  Sttxfy  Wottat 
Comments: 


Navigation  Technique 
Dead  Reckoning 


Inertial  Navigation 


Acoustic  Baseline 
Radio  Navigation 


8y*tamSCofnpon*nt 

Type 

V«oc*y  S«naon 


Hearing  Soraon 


AKilvrti  S mntar 
Dmc** 

Roii  pAcft 

Srfxnd  SpMd  SMOt 
Gv^oecop# 


IMU 


Long  Basel ne  (LBL) 
Ultra-Short  BL  (USBL) 
GPS 


GLONASS 


1  Item 

Model 

Length  (In) 

Length  Dim 

Width  (In) 

Width  Dim 

Height  (In) 

Volume(cu  In) 

1  EM  LOG 

AGILOG 

8.0 

dia 

8.0 

dia 

11.4 

573.0 

2  DVS 

microDVL 

5.5 

dia 

5.5 

dia 

5.0 

118.8 

3  Correlation 

ACCP 

17.3 

- 

17.3 

- 

8.7 

2603.8 

4  Compass 

Cl  00 

4.5 

- 

1.8 

- 

1.1 

8.9 

5  Gyrocompass 

GyroTrac 

7.8 

- 

5.0 

- 

5.1 

198.9 

6  North-finding  gyro 

MintFOG 

11.8 

dia 

11.8 

dia 

16.0 

1749.7 

7  Altimeter 

PSA-900 

4.0 

dia 

4.0 

dia 

11.5 

144.5 

8  Depth  Sounder 

TJE 

1.5 

dia 

1.5 

dia 

2.0 

3.5 

9  Clinometer 

AccuStar 

2.5 

dia 

2.5 

dia 

1.2 

5.9 

10  Inclinometer 

TCM2 

2.5 

- 

2.0 

- 

1.3 

6.3 

11  CTD 

MicroSVP 

2.9 

dia 

2.9 

dia 

13.8 

93.7 

12  Velocimeter 

Smart  Sensor 

1.8 

dia 

1.8 

dia 

12.4 

31.6 

13  Mechanical 

RG78 

3.7 

dia 

2.0 

dia 

1.8 

19.0 

14  Ring  laser  gyro 

GG1320 

3.5 

dia 

3.5 

dia 

1.8 

16.5 

15  Fiberoptic 

Ecore  100 

4.3 

- 

3.5 

- 

1.6 

24.1 

16  MEMS 

Gyrochip  QRS11 

1.5 

dia 

1.5 

dia 

0.6 

1.1 

17  Mass-spring 

LA67 

1.0 

dia 

1.0 

dia 

2.5 

2.0 

18  Pendulous 

LSBC 

2.6 

- 

1.2 

-- 

1.4 

4.4 

19  MEMS 

CXL02F3 

2.0 

- 

1.2 

- 

0.9 

2.1 

20  IMU  1 

TGAC-RC 

7.9 

- 

8.7 

- 

13.8 

939.2 

21  IMU  2 

LN-200 

3.5 

dia 

3.5 

dia 

3.4 

322 

22  IMU  3 

Motion  PAK 

3.0 

- 

3.0 

- 

3.6 

32.4 

23  Omni-directional 

Trackpoint  II 

2.8 

dia 

2.8 

dia 

24.0 

142.5 

24  Super-directional 

Type  7978 

72 

dia 

7.2 

dia 

39.5 

1608.2 

25  Civilian  Rcvr 

Sensor  II 

4.2 

— 

2.3 

- 

0.6 

5.7 

26  DGPS  Rcvr 

DSM212L 

7.7 

- 

5.7 

- 

2.0 

87.8 

27  Military  Rcvr 

12  MPE-1 

42 

- 

2.7 

- 

0.6 

6.8 

28  Receiver 

GG24 

6.5 

- 

4.0 

- 

0.6 

15.6 
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COMMUNICATIONS  DATABASE 


Source:  None 

Comments:  Rough  guesses  only  --  need  to  build  database 


Desig 

Wt 

Vo  1 

Power 

ibs 

cu  in 

w 

Acoustic  Modems 

AM 

1.5 

37.03 

9 

Laser  Modems 

LM 

Future 

Future 

Future 

RF  Units 

RF 

1 

24.69 

3 

Combinations 

AM  +  RF 

2.5 

61.71 

12.00 

COMPUTER/PROCESSOR  DATABASE 


Source:  MCM  Future  System  W G 

Comments:  Traditional  sensors  listed  here;  see  WG  paper  for  more  advanced  concepts 


Computer/Processor  Type 

Desig 

Wt 

Vol 

Power 

Ibs 

cu  in 

w 

Basic  Guidance,  &  Control  &  Veh  Housekeeping 

GC 

2 

75.00 

15 

Basic  G&C  +  Kalman  Filter 

GC+K 

3 

100.00 

20 

Basic  G&C  +  Kalman  Filter  +  Sonar  Post-Processor 

GC+K+S 

4 

300.00 

40 

112 


Bibliography 


[1]  U.S.  Navy  Unmanned  Undersea  Vehicle  (UUV)  Master  Plan.  Naval  Undersea  Warfare 
Center,  Newport,  RI,  April  2000. 

[2]  “Concept  of  Operations  For  Mine  Countermeasures  in  the  21st  Century.”  Chief  of  Naval 
Operations  (N852),  1  September  1995. 

[3]  “A  Concept  for  Future  Naval  Mine  Countermeasures  in  Littoral  Power  Projection.”  U.S. 
Marine  Corps  Combat  Development  Command,  1  May  1998. 

[4]  Undersea  Vehicles  and  National  Needs.  National  Research  Council.  National  Academy 
Press,  Washington,  D.C.,  1996. 

[5]  Technology  for  the  United  States  Navy  and  Marine  Corps,  2000-2035:  Becoming  a  21st- 
Century  Force:  Volume  2:  Technology.  National  Research  Council  Committee  on  Technol¬ 
ogy  for  Future  Naval  Forces.  National  Academy  Press,  Washington,  D.C.,  1997. 

[6]  Office  of  Naval  Research.  “New  Mine  Countermeasure  Technologies  Demonstrated  in  Naval 
Exercise.”  News  release,  23  August  2000. 

[7]  MCM  Future  Systems  Study  Workbook,  Version  2.3.  Applied  Physics  Laboratory,  Johns 
Hopkins  University;  Advanced  Research  Laboratory,  University  of  Texas  at  Austin;  Naval 
Surface  Warfare  Center  Dahlgren  Division/Coastal  Systems  Station,  Panama  City,  FL; 
October  2000. 

[8]  H.  Schmidt,  et  al.  “Sensor  and  Operational  Tradeoffs  for  Multiple  AUV  MCM.”  Massa¬ 
chusetts  Institute  of  Technology  Sea  Grant  proposal  to  Office  of  Naval  Research,  May 
1999. 


113 


[9]  H.  Schmidt,  et  al.  “GOATS  ’98  -  AUV  Network  Sonar  Concepts  for  Shallow  Water  Mine 
Countermeasures.”  Technical  Report  SACLANTCEN  SR-302,  SACLANT  Undersea  Re¬ 
search  Centre,  La  Spezia,  Italy,  1998. 

[10]  T.  Curtin,  J.  G.  Bellingham,  J.  Catipovic,  and  D.  Webb.  “Autonomous  Oceanographic 
Sampling  Networks.”  Oceanography,  6(3),  pages  86-94,  1993. 

[11]  J.  J.  Leonard,  et  al.  “Autonomous  Underwater  Vehicle  Navigation.”  Massachusetts  Insti¬ 
tute  of  Technology  Marine  Robotics  Laboratory  Technical  Memorandum  98-1,  1998. 

[12]  Implementation  of  Mandatory  Procedures  for  Major  and  Non-Major  Defense  Acquisition 
Programs  and  Major  and  Non-Major  Information  Technology  Acquisition  Programs.  Sec¬ 
retary  of  the  Navy  Instruction  (SECNAVINST)  5000.2B,  6  December  1996. 

[13]  W.A.  Hockberger.  “Total  System  Ship  Design  in  a  Supersystem  Framework.”  Naval  Engi¬ 
neers  Journal,  pages  147-169,  May  1996. 

[14]  C.  A.  Whitcomb.  A  Prescriptive  Production-distribution  Approach  for  Decision  Making  in 
Product  Design  Engineering.  UMI  Company,  1999. 

[15]  Mine  Warfare  Measures  of  Effectiveness  and  Measures  of  Performance.  U.S.  Navy  Program 
Executive  Office  for  Mine  Warfare  (PEO(MIW))  Instruction  3370,  July  1998. 

[16]  Y.  Akao.  Quality  Function  Deployment:  Integrating  Customer  Requirements  into  Product 
Design  .  Productivity  Press,  Cambridge,  MA,  1990. 

[17]  T.  L.  Saaty.  Multicriteria  Decision  Making:  The  Analytical  Hierarchy  Process.  RWS  Pub¬ 
lications,  Pittsburgh,  1990. 


114 


